In the world of computer languages, nothing speaks louder than who adopts its usage. The Python language hit a home run with Google adopting it for a high percentage of their internal and public (Google App Engine) projects. One of the things that makes the Python language appealing to so many is how it treats everything as an object. This makes the language inherently object-oriented but not so complex and wordy that it can’t be understood by beginning programmers.
This article will give an overview of the basic object-oriented concepts in Python. We’ll start by defining an object and learning what it is. Next, we’ll take a look at how you can discover the properties of Python's built-in objects and how you can create your own. Then we’ll finish off with a list of best practices and a pointer to where you can go to get more information.
Introduction
The Python language is growing in acceptance and has made itself useful for a variety of purposes and platforms, everything from mobile phones to major websites to windowed applications and more. With so many ways to employ the language, a standardized method for sharing functionality in an extensible fashion is imperative. Fortunately, Python has provided the solution to its own problem in the form of objects.
An object is an entity defined by a class containing attributes and methods which can be inherited and can also inherit functionality from others in a variety of scopes. Objects simplify writing reusable code, thereby making the development process faster and more efficient. Objects are not unique to the Python language, but there certainly are some unique aspects. For instance, Python uses underscores in attribute names to mark accessibility rather than taking the traditional method of using keywords, thereby decreasing the amount of code needed. Note the contrast between Python and Java shown below.
Python:
When delivering software libraries, a developer needs to have a standardized way to allow for others to extend and integrate the functionality they are providing. Using objects and inheritance, this is made simple.
Syntax
Here is some of the syntax for Python.
Class Definition
A class defines the behavior and attributes of an object. It is the blueprint, if you will, for an object. Note that Python uses the # symbol to denote comments, so those lines are not executable parts of the program. The basic syntax looks like this:
![]()
The first line is the class keyword followed by the name of the class, any parent classes (more on that later), a colon, and a code block containing the body of the class. (pass is just a place-holding keyword)
Attributes
An attribute is created by a variable assignment within the scope of the class body as in this example:
This creates an attribute name whose value is a string John Doe. Now we can access the attribute as if it were a variable by combining the object and attribute names with a dot in the following manner:
Classes vs. Instances
A class and an instance are two different but related things. A class is a type while an instance is a single occurrence of some class. To create an instance (also known as "instantiating a class") call the class as if it were a function including any arguments to pass to the constructor (more on that later):
Now we have an instance of the Person class called my_instance. As you can see, it shares much the same initial state as the class itself, but just a little experimentation will show that they are now separate and distinct entities.
Methods
This part assumes you know how to declare a function, but in the event you do not you can copy the examples shown here.
A method is to a function what an attribute is to a variable. That is, they are the same except that one is defined as the child of a class/object. A method is simply a function defined within the scope of a class or, more appropriately, a callable attribute. Take this example:
This basic instance method simply prints out the name of that Person. The self argument is automatically supplied when the method is called and is a reference to this particular instance:
Here we instantiated the Person class, used the print_name method, changed the name attribute, and called the method again with the new value.
It can Inherit Functionality
Python uses base classes, or super classes, to allow developers to take advantage of library functionality. A super class is a class that defines attributes and methods that can then be inherited by other classes. Let's say we want to make another type of Person called a Plumber, and we want to change the name attribute. We could reuse our existing class to avoid repetition and speed up the development process:
With a single word we've inherited whatever functionality may be found in the base class. We then replace or override the attribute with these results:
Now we can extend and customize existing objects however we need to. What if we want to combine functionality from two or more base classes? Here’s an example:
We've added a base class that defines another attribute, gender, and changed the Plumber class to inherit from both Person and Man. If we play around with our new Plumber class, we can see that the attributes and methods of the two classes have now been merged.
Constructors
Now that we've covered instantiation, methods, and inheritance, let's see how they overlap. You probably noticed from the first class example that basic classes inherit from object. This is a Python base class that provides a standardized control mechanism for objects. All of your classes should trace back to object. One of the methods the object class provides is the constructor or __init__ method. When you instantiate a class, the arguments passed to the call are directed to the constructor which is always run at instantiation. Let's add a constructor to our Person class to make things a little more dynamic:
So now when we instantiate a person we can pass in the name to the constructor rather than having to assign the attribute later. We also provided a default value for the argument in case the user leaves it empty. You'll notice we're calling the parent constructor. Backward compatibility is maintained since the constructor will run in the same way with no arguments as seen in this example:
What to Do With Conflicting Attributes
If you frequently use multiple inheritance you may have to take a little more time to merge two classes into one. The first listed class takes precedence over any others and overrides any other parent classes. Here's an example of conflicting methods:
Now we've modified the Man class to have its own print_name method to add the prefix to the hard-coded name. In addition, we’ve removed the attribute definition in the Plumber class since that's now supplied via the Person constructor. At this point we have a problem if we wanted to use that nifty new print_name method with the Plumber class since Person.print_name takes precedence over Man.print_name as seen in the following example.
So we can just do this, right?
Wrong! This will raise an exception since the constructor for Man is overriding the constructor for Person which takes an argument. We need to take just the constructor from the Person class and let the Man class override everything else. Here's how to do it:
So all we did here is write our own constructor using wildcards to catch all positional arguments (those passed in without a name associated with them) and keyword arguments as args and kwargs to pass on to the Person constructor. Obviously, the Man constructor takes no arguments.
Conclusion
Objects are an easy and efficient way to expose your code for others to use and to combine different features to build the ultimate programming experience. You should use them when possible in your programming to allow for reuse at later times. Be sure to document and test your code!

written by Miguel, November 09, 2009
Try it yourself:
>>> type(5)
>>> dir(int)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
>>> int(5)
5
>>> int("5")
5
written by linuxjosh, November 09, 2009
Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1
1
>>> 1.hi = 5
File "", line 1
1.hi = 5
^
SyntaxError: invalid syntax
>>> class Foo(object): pass;
...
>>> Foo()
>>> Foo().hi = 2
>>> f = Foo()
>>> f
>>> f.hi = 5
>>> f.hi
5
>>> quit()
written by Alan, November 09, 2009
File "", line 1
1.foo
^
SyntaxError: invalid syntax
>>> (1).foo
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'int' object has no attribute 'foo'
>>> dir(1)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__format__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'conjugate', 'denominator', 'imag', 'numerator', 'real']
>>> 1.real
File "", line 1
1.real
^
SyntaxError: invalid syntax
>>> (1).real
1
>>> a = 1
>>> a.real
1
Notice the difference between (1).foo and 1.foo -- you can't use the syntax with a literal, but the reason for that is purely syntactic, not semantic: 1.real looks like 1.0 (a floating point literal), except malformed.
written by josh, November 09, 2009
Funny you should say that Alan, but it looks like you still can't set arbitrary properties of an int like you can an object:
>>> 1
1
>>> 1.hi = 10
File "", line 1
1.hi = 10
^
SyntaxError: invalid syntax
>>> (1).hi = 10
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'int' object has no attribute 'hi'
written by Leo Horovitz, November 09, 2009
written by josh, November 09, 2009
> I don't think it treats numbers as objects.
That's hardly what I would call 'attempted proof of the non-qualification of numbers as objects'. It's more like a 'question'.
written by Alan, November 09, 2009
Not being able to set arbitrary properties on an object doesn't make it a non-object. In fact, you can create immutable objects yourself if you learn about meta-classes and all that. Ever since the introduction of "new style classes" several versions ago. Prior to that the built-in types were special, indeed.
There's nothing special about built-in types except for them being able to be created from literals and even that could be emulated with custom encoding filters (think of them as preprocessors).
If you're surprised by the way these things work in Python, you'd probably be surprised about this too: there is no such thing as "private" properties in Python (at least not in the sense you'd expect it coming from C++/Java): prefixing private properties with an underscore is merely a convention. In fact, class-private properties (i.e. anything you don't want child classes to overwrite) can easily be marked with a double-underscore prefix, which will automatically be replaced with the class's name (at runtime, I think), so MyClass.__secret becomes MyClass._MyClass__secret!
And here's the real kicker: Python is strongly typed and dynamic typed (for comparison: C/C++ are weakly typed but statically typed and scripting languages like PHP are both weakly typed AND dynamically typed). This is why the Pythonic way of dealing with inheritance is called duck typing: as long as the object behaves as expected, you shouldn't reject it. This makes it trivial to create wrapper classes.
Indeed, Python's strictness is more about contracts (i.e. expecting the dev to do the right thing and telling them what you expect) than arbitrary prescriptions embedded in the programming. This is fundamentally different from languages like C++ or Java which tend to go for strict, static typing and inheritance checks to enforce correctness.
And finally, Python is much more like Java or C# than like Perl or PHP in terms of how it is executed. While CPython allows for on-demand compilation (and thus makes it easy to reload a modified module at runtime) it does actually compile Python into bytecode to be executed on its VM. Jython (for the JVM), IronPython (for .NET) and Pirate (for the Parrot VM) work similarly, except they target specific common VMs. So much for Python being just another scripting language.
written by Leo Horovitz, November 09, 2009
written by josh, November 09, 2009
My question was perfectly clear and I showed what led me to ask my question.
I gave no definite answer, I said,"it looks like you still can't set arbitrary properties of an int like you can an object", which is indeed true.
A more appropriate response might have started with "You can't, but they are still objects because..." instead of "If you don't know, it's sometimes better to just shut ..."
Thanks for making the Python community a better place.
written by Leo Horovitz, November 09, 2009
In your first post, I found nothing wrong at all. The phrase "I don't think it treats numbers as objects." is perfectly reasonably interpreted as a question, to demand a rephrasing of it to "is numbers treated as objects?" would be ludicrous nit-picking.
In your second post though, you wrote "Numbers are not treated the same as objects.", which I quoted in my last post along with the claim that this could not reasonably be interpreted as a question. This claim however, can be interpreted as begging an implied question (see I can make them too) urging you to please supply the means by which you can reasonably make this interpretation (of this phrase as a question that is, which I included to aid in your brain's parsing of my writing). In this post, you displayed apparent certainty in the matter, especially since you also supplied Python code to go along. Since you displayed a lack of knowledge of basic Python syntax in this post, Alan was perfectly justified to snap at you for filling up this comment thread with an amatuer's attempts at answering question for which he's not qualified to answer, a phenomenon which is much more of a contributor toward lowering the standards of this or any other community than rudeness, which is actually the appropriate tool for diminishing the aforementioned problem.
Upon receiveing Alan's response, you continued to reply as if you actually had any knowledge of this matter, ironically while further proving that the opposite is true. No stop whining, and stop answering question as if you were knowledgeable in the subject when you are clearly not!
written by Leo Horovitz, November 09, 2009
written by Alan, November 09, 2009
That statement was obviously false and would have given people the wrong ideas about how Python works, so I debunked it, assuming (making an ash out of you and Ming) that you were trying to make a point.
But regardless -- don't take my sociopathy as representative for the Python community. Relative to other languages Python actually does rather well in this regard (i.e. number of p***ks per community size).
written by josh, November 09, 2009
written by Leo Horovitz, November 09, 2009
Regarding your supposed innocence in stating anything as a fact, how about the phrase that I have quoted directly two time now, accompanied by an explicit question the second time after recieving now response to the implicit one from the first quotation: "Numbers are not treated the same as objects". If you do not understand how this is a statement, I have another thing you need to read: http://en.wikipedia.org/wiki/Statement_(logic). You see, when write phrase of the form "x is not y", this is a statement! When you want to formulate a question, you instead use the form "is x y?", "is x not y?" or possibly something along the lines of "I thought x was not y?". Now go learn some more Python, english, propositional & predicate logic and any other formal and informal languages needed to conduct a simple conversation about this topic.
written by josh, November 09, 2009
> Numbers are not treated the same as objects
That was not a question, and it is still a correct fact.
As a side note, it looks like linux.com may not be correctly ordering these responses:
your "I don't think you're being a p***k at all!" message appears right above Alan's message that mentions "(i.e. number of p***ks per community size). "
written by Leo Horovitz, November 09, 2009
So now youäve changed your position? Last message you claimed to not have made a statement, now you admit it was a statement but claim that it's true despite having been shown why it's not? If you had read and understood our responses, you would understand that while it is certainly the case that numbers are treated differently than other objects (you see that word there before the word "objects", "other", that implies that numbers are also objects, otherwise I would have written that numbers are treated differently than objects, without that word "other"), this does not mean that numbers are not objects. As Alan stated above, immutable objects are also objects and numbers are not alone in being immutable. As I expect you do not know the meaning of the word "immutable" I will supply it here for you: it means that it can not be modified. If you understand what I have just explain (which I doubt) you will see why the statement "Numbers are not treated the same as objects" is false since it implies that numbers are not objects, which they are. Just stop this crap now, you're just embarrassing youself further and further.
written by josh, November 09, 2009
That was not a question, that was a statement.
>but it looks like you still can't set arbitrary properties of an int like you can an object:
That is a statement that is not presented as a statement of fact, but as an observation of the code that followed it. The big clue is the phrase "it looks like", which is not an absolute truth.
An astute read would realize that I have both asked questions and made statements.
I do understand what immutable means. I appreciate what Alan said that answered my questions, but your continued belligerence really demeans the Python community and this site. You'd be ashamed of yourself if you had any sense, but you don't. I'll let you find the link for the definition of 'belligerence' and 'astute', as I see you are already pretty good at looking things up.
written by Leo Horovitz, November 09, 2009
> Numbers are not treated the same as objects
That was not a question, and it is still a correct fact.
Something I dedicated a far among of space to proving wrong in my last post and which you never responded to.
As for this:
>but it looks like you still can't set arbitrary properties of an int like you can an object:
That is a statement that is not presented as a statement of fact, but as an observation of the code that followed it. The big clue is the phrase "it looks like", which is not an absolute truth.
That is blatantly dishonest! I never said every sentence in every one of your posts displayed certainty, only that you did display apparent certainty in matters where you have proven yourself ignorant. The post you quoted from there had this as a title: "Still not treated the same as an object", again an apparent statement of fact, and a false one at that! Furthermore, your usage of the word "statement" is suspect. There are two different meanings of this word that you seem to confuse. The first one is synonymous with sentence and can thus refer both to sentences declaring thing, and sentences asking questions. The other meaning is the one from logic where a statement is a declarative sentence only. Your usage of statement in two different ways in the same sentence above: "That is a statement that is not presented as a statement of fact" is thus weird as statements in the sense from logic can only be statements of fact. The only way to make sense of that sentence is to interpret the first usage of the word "statement" as meaning the other kind of statement, the one that is not necessarily declarative. If this is what you intended, then you are again using misleading language, though I suspect it stems more from ignorance, much like most other thing you have written here.
I'm getting real tired of pointing out all your errors time and time again only to have you respond without directly adressing my claims.
written by josh, November 09, 2009
written by Leo Horovitz, November 09, 2009
You know, when a person (lets call him Leo) points out another person's (lets call him Idiot) errors time and time again, gets no sensible respons to any of it (only whining, red herrings and factual errors), gets tired of the BS, points out the fact that Idiot has failed to respond accordingly (naively expecting Idiot to care about adherring to basic argumentative principles and thus to respond) and gets back a respons like that, it tends to strengthen said person's (Leo's) hypothesis that Idiot is in fact, an idiot, not weaken it.
By the way, excellent deduction there! Clearly my rudeness, "nastiness" (Waa, waa!) and the fact that I made some claims about your sentences being statements (which you tried to dispute, unsuccesfully) are sufficient to draw conclusions regarding my programming skills! You, sir, win the internet!
Want to know about my programming skills? Ok, I've been programming for more than 10 years, have used C/C++, C#, Java, Javascript, Pascal, PHP, Python, Ruby, LISP, Smalltalk, Haskell, etc. I've studied computer science at university for a few years, have been in several large projects for assignments, have worked part time for a company with their website in flash and built from scratch a web portal in PHP (with MySQL for database, running on an Apache server) for their customers to use, and I'm currently finishing my bachelor thesis on type systems for object oriented languages where I write about different approaches to static typing in object oriented languages of different kinds, you know class-based vs prototype-based, nominal typing vs structural typing, second order typing, subtyping, different ways to encode object calculi in variants of lambda calculus (and vice versa), the kind of things anyone who's read some papers by Luca Cardelli, Philip Wadler, Benjamin Pierce, et al. have written. You have read those haven't you? You have also read Pierce's "Types and Programming Languages" right, and Cardelli's "A Theory of Objects"? You're not the kind of person to speak about these matters without having read some academic papers and books first right? No, nothing you've said here indicates that!
written by josh, November 09, 2009
written by Leo Horovitz, November 09, 2009
Leo: "That was a statement!"
Idiot: "Nuh-uh!"
Leo: "Yes it was, here's why: ..."
Idiot: "This other sentence was a statement, and a corrent one!"
Leo: "No, I already explained why it's wrong, let me do that again!"
Idiot: "Your mother takes angel dust! You don't know anything about programming!"
Leo: "Excellent respons! Here's a short summary of my programming history: ..."
Idiot: "You make factual errors!"
Which leads us to the current location in the thread at which point I reiterate: What factual errors? If you are going to attempt a respons, I want quotations. If the supposed errors are related to something I have already covered, with thorough explanations of why every sane person must consider the sentences I called statements as, in fact, statements and that the sentence which you agreed was a statement was making a false claim, then please supply an equally thorough explanation of where exactly I made these factual errors. You're just continuing with the stupidity. Now do something right for once, back up the claim you made in the last post or shut up!
written by josh, November 09, 2009
You said you only got 'factual errors' in response from me. Your reading comprehension is piss-poor. You need some more Reading Rainbow.
written by Leo Horovitz, November 09, 2009
In response to that, you said this:
Yeah, I only point out your factual errors. We shouldn't bother ourselves with such trivial things as factual errors. You are indeed as funny as your picture is.
To which I responded: "Which factual errors?" Now I have another question for you: Where did I misunderstand something there? You claimed to point out my factual errors, I asked which those errors were, seems like a pretty reasonable respons to me. Now disregard the rest of the conversation for the moment. Instead, answer just one of the questions from this post which I reiterate again here:
(1) Which factual errors? (that I have made, which you accused me of in the part I quoted last paragraph)
(2) How exactly did my last respons indicate that I had misunderstood you?
written by josh, November 09, 2009
Those are the factual errors that I was referring to, the ones that you mentioned above. The above is a direct quote from you. Again, your reading comprehension is piss-poor.
written by Leo Horovitz, November 09, 2009
Now finally you tell me what factual error I made, supposedly I was wrong in saying all you had responded with was factual errors, whining and red herrings, which I think was a fair characterization of your contributions to this "discussion" seeing as how our main disagreements where about: (1) the status of numbers as objects in Python (you claimed they're weren't objects, me and Alan explained why you were wrong, that's one of your factual errors), (2) the fact that you had made statements as opposed to simply asking questions (something both me and Alan explained to you clearly and which I continued to explain, you did form sentences which, properly interpreted, come out as declarative statements, not questions), and (3) the fact that the sentence you did agree was a statement was false (which it is, something I explained carfully above, the sentence implied that numbers aren't object, they are, hence the statement was false). Between these factual errors, you have whined about our "nastiness" (which I call whining since said nastiness is absolutely deserved, right from the start, as a response to the level of stupidity that you have displayed, idiots should not be treated in a friendly manner, especially not if they are not aware of their stupidity) and made a few red herrings by refusing to respond directly to my accusations of factual errors by shifting focus to some other point.
You are tiring me, and any one else who might happen to see this, out. You are disrupting serious debate, you are ignorant of basic logic and argumentation skills. This attempt at discussion has sunk to the level of YouTube comment threads and it's insulting to the intelligence of everyone here. Now learn something from this experience, the next time you feel like commenting on something, either pick something you know a lot about, or take a very humble approach, only producing sentences that are clearly (and not just supposedly, meaning for one that they have to end with a question mark) questions. Don't write anything that even looks like a declarative sentence unless it is about something you have studied in dept, that's how serious discussion are conducted.
written by josh, November 09, 2009
With an imbecile like you? You can't even recognize a question unless you see a question mark. For the third time: your reading comprehension is piss-poor.
written by Leo Horovitz, November 09, 2009
written by Leo Horovitz, November 09, 2009
written by josh, November 09, 2009
Rhetorical question (You can look that one up.)
> You can't even recognize a question unless you see a question mark.
Not a question
> For the third time: your reading comprehension is piss-poor.
Not a question
written by Leo Horovitz, November 09, 2009
Back to the lecturing! Again, answer me directly. Is the following phrase a question?
"Numbers are not treated the same as objects"
written by Alan, November 10, 2009
Guys, would you please stop it already? We're quarrelling over semantics and Josh obviously either lacks the capabilities or is not interested in discussing objectively (seriously, that "your mom" remark was off the line). There's obviously a divide between how Josh intended his initial posts and how they were parsed (although I think we've made clear WHY they were parsed that way). You don't need a forensic linguist in order to figure out that the statement "A." in a chain of "A? A. B. B→A" is an assertion, not a question).
Josh, I hope you see why the assertion "Numbers are not treated the same as objects" includes the sub-statement "Numbers are not objects", which I have tried to prove false to you (search for Python and "new style classes" if you still don't believe me). I hope you can also see how my post was primarily intended to debunk the one preceding it, i.e. the assertion (with the example of how an int throws an exception where a "normal" object works fine, which is true, but for the wrong reasons).
I'm sorry if you took my tone to be overly harsh, but you'll find that it's not particularly unique to "the Python community" (which I assure you is too abstract and heterogenic a group to draw conclusions about from intepreting one specimen) and the only ad hominem statement it implied was "You have no idea what you are talking about" (which you haven't, as you proved by initially asking something, then asserting it and then backing it up again despite having been told the opposite -- and being wrong, which is perfectly fine as long as you don't insist on being right despite evidence to the contrary).
There's no need to get insulting for insult's sake. If you feel offended by what someone said, first make sure it's what they intended to say (maybe I did forget to do this, too, but your assertion did come off as rather emphatic). Don't take anything personally and don't post merely to "fight back". When you try to make an argument, try to provide a valid one, don't get distracted by your own emotions towards what has been said. Think about what they said and what they may have MEANT. This isn't always easy (evidently, at least two people found what you said to be heavily dissociated from what you now claim to have meant).
So let's all please cut down on the trolling and flaming. Both sides.
The actual topic was "Is it really true that every type in Python is an object type, even primitives?" and the answer is "Yes, it is. Python does not treat primitives different from any other type of objects." -- more specifically, this has been true since around version 2.2 or so, when the new style classes were introduced, which means exactly that (the only two types that are in any way special are "type" and "object" and they're only special semantically, because most classes are derived from "object" (the type "object", not "an object") and all types/classes (even the type "type") are instances of the type "type". This only means types are objects too, just like anything else. It's only confusing if you come from something like C++ or Java (but even in Java every class is an object of class "Class").
written by Leo Horovitz, November 10, 2009
As an attempt to make up for my part in clogging this thread with useless content, I'll try to fill it with something useful in the form of an enquiry about a statement you made there regarding classes in Java. I definitely don't have any deep knowledge of the workings of the JVM, but isn't a class object in Java essentially different from class objects in Python? In Python it seems to work like in most other dynamic object-oriented languages (Ruby, Smalltalk, etc.) where the very definition of a class yields the instantiation of it's class at run-time, resulting in a new class object which is a necessary precondition for creating instances of it. Doesn't the instantiation of a class in such languages always consist of the invocation of a method defined on the class object (the '__new__' method in Python)? In Java, it is certainly possible to get a class object which has a 'new' method for creating new instances, but if I understand it correctly, this is not part of the normal process of instantiating classes. Isn't this something that is built on top of the core system in the form of a library to facilitate dynamic features that in languages like Python, are at the very core of the language? Or is this a misunderstanding?





















I don't think it treats numbers as objects.