Re: Trying to understand Python objects
In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Typically, classes are created as a subclass of another class. The top-level basic type in Python is 'object', so if your class doesn't make sense deriving from anything else, derive from 'object'. class Point(object): pass Defining a class with *no* superclass is not recommended. If you don't yet understand the difference between the above style (called a new-style class) and the style you presented, you should always derive from a superclass ('object' or something more specific) until you encounter a situation where that causes a problem. Side note: I disagree with the above advice, but it's Thanksgiving and I don't have enough room on the margin for the proof. I think classic classes are just fine. Don't see it as a religious point please, but I fail to understand why you seem so in love with old-style classes ? new-style classes are the official Python object model since 2.2 (which is a few years ago now), and the last mandatory use of them (exceptions...) disappeared with the 2.5. AFAIK, everything you do with old-style classes can be done with new-style ones. FWIW, old-style classes support is now only for backward compat. So *why* insisting on using them ? There's a big difference between saying always use old-style classes and classic classes are just fine. So I'm certainly not in love with or insisting on using classic classes. Mostly what I'm saying is that I think it's kinda gross and grotesque for newcomers to be told to use class Point(object): pass instead of class Point: pass You are also wrong about new-style classes being the official object model -- the tutorial doesn't even mention them yet! I also think that new-style classes should be avoided in Python 2.2 because of the subtle differences that were introduced in 2.3 -- and 2.2 is still in active use. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ In many ways, it's a dull language, borrowing solid old concepts from many other languages styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it. --Tim Peters on Python, 16 Sep 1993 -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Typically, classes are created as a subclass of another class. The top-level basic type in Python is 'object', so if your class doesn't make sense deriving from anything else, derive from 'object'. class Point(object): pass Defining a class with *no* superclass is not recommended. If you don't yet understand the difference between the above style (called a new-style class) and the style you presented, you should always derive from a superclass ('object' or something more specific) until you encounter a situation where that causes a problem. Side note: I disagree with the above advice, but it's Thanksgiving and I don't have enough room on the margin for the proof. I think classic classes are just fine. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ In many ways, it's a dull language, borrowing solid old concepts from many other languages styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it. --Tim Peters on Python, 16 Sep 1993 -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
In article [EMAIL PROTECTED], walterbyrd [EMAIL PROTECTED] wrote: Is there some book, or other reference, that explains of this? I was thinking about Python for Dummies. The Think like a Computer Scientist book, and Dive into Python book don't seem to explain Python's object model clearly enough for me. Speaking as the co-author of _Python for Dummies_, we certainly tried to make much of this clear, but I haven't seen any reviews yet (partly our fault for not getting out review copies). -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ In many ways, it's a dull language, borrowing solid old concepts from many other languages styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it. --Tim Peters on Python, 16 Sep 1993 -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Aahz a écrit : In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Typically, classes are created as a subclass of another class. The top-level basic type in Python is 'object', so if your class doesn't make sense deriving from anything else, derive from 'object'. class Point(object): pass Defining a class with *no* superclass is not recommended. If you don't yet understand the difference between the above style (called a new-style class) and the style you presented, you should always derive from a superclass ('object' or something more specific) until you encounter a situation where that causes a problem. Side note: I disagree with the above advice, but it's Thanksgiving and I don't have enough room on the margin for the proof. I think classic classes are just fine. Don't see it as a religious point please, but I fail to understand why you seem so in love with old-style classes ? new-style classes are the official Python object model since 2.2 (which is a few years ago now), and the last mandatory use of them (exceptions...) disappeared with the 2.5. AFAIK, everything you do with old-style classes can be done with new-style ones. FWIW, old-style classes support is now only for backward compat. So *why* insisting on using them ? wondering... -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Bruno Desthuilliers wrote: AFAIK, everything you do with old-style classes can be done with new-style ones. The only thing I occasionally (or rather rarely) miss about old-style classes is instance-specific special methods: class C: ... def __init__(self,x): ... self.__getitem__ = lambda i: i*x ... c=C(2) c[3] 6 class N(object): ... def __init__(self,x): ... self.__getitem__ = lambda i: i*x ... n=N(2) n[3] Traceback (most recent call last): File stdin, line 1, in ? TypeError: unindexable object Of course this example can be rewritten to work for new style classes; a trickier would be to bind the instance attribute conditionally; here's a silly example: class C: ... def __init__(self,x): ... if random.random() 0.5: ... self.__getitem__ = lambda i: i*x I'm not sure if this is a conscious choice or a technical limitation of how new-style classes work internally, but I've had a use for it at least once. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Bruno Desthuilliers wrote: Don't see it as a religious point please, but I fail to understand why you seem so in love with old-style classes ? new-style classes are the official Python object model since 2.2 (which is a few years ago now), and the last mandatory use of them (exceptions...) disappeared with the 2.5. AFAIK, everything you do with old-style classes can be done with new-style ones. FWIW, old-style classes support is now only for backward compat. So *why* insisting on using them ? to pick a few reasons: the old-style/new-style distinction is com- pletely irrelevant for people new to the language, attribute access is slower for new-style classes (!), they'll be default in 3.0 any- way... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Fredrik Lundh a écrit : Bruno Desthuilliers wrote: Don't see it as a religious point please, but I fail to understand why you seem so in love with old-style classes ? (snip) to pick a few reasons: the old-style/new-style distinction is com- pletely irrelevant for people new to the language, Until they try to use properties... -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Aahz wrote: In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Typically, classes are created as a subclass of another class. The top-level basic type in Python is 'object', so if your class doesn't make sense deriving from anything else, derive from 'object'. class Point(object): pass Defining a class with *no* superclass is not recommended. If you don't yet understand the difference between the above style (called a new-style class) and the style you presented, you should always derive from a superclass ('object' or something more specific) until you encounter a situation where that causes a problem. Side note: I disagree with the above advice, but it's Thanksgiving and I don't have enough room on the margin for the proof. I think classic classes are just fine. Absolutely. We don't want newbies' feeble brains to explode. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
walterbyrd wrote: 1) Can attributes can added just anywhere? I create an object called point, then I can add attributes any time, and at any place in the program? in general, yes, but that should be done sparingly. 2) Are classes typically created like this: class Point: pass Then attributes are added at some other time? no, classes with attributes are typically created like this: class Point: def __init__(self, x, y): self.x = x self.y = y p = Point(1, 2) i.e. attributes are created in the initialization function. 3) What is with the __underscores__ ?? they're reserved for use by the interpreter, usually for calling special methods in you class: http://effbot.org/pyref/reserved-identifier-classes http://effbot.org/pyref/special-method-names 4) Are parameters passed to an class definition? class Whatever(params): pass no, that's the syntax used for inheritance. arguments passed to the class constructor are passed on to the initialization function (see the example above). for more on this, see the tutorial. Jay Parlar's gentle introduction from the community tutorial might be helpful: http://effbot.org/pytut/node11-baseline.htm /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
walterbyrd wrote: Reading Think Like a Computer Scientist I am not sure I understand the way it describes the way objects work with Python. 1) Can attributes can added just anywhere? I create an object called point, then I can add attributes any time, and at any place in the program? Apart from a few special cases (mainly builtin types or new-style classes using slots IIRC), yes. Now wether this is a good idea is another question. As far as I'm concerned, I do use this feature, but only for special cases, and almost only in metaclasses or other special 2-stages init. 2) Are classes typically created like this: class Point: pass Then attributes are added at some other time? Nope. The canonical idiom is to use the initializer: class Point(object): def __init__(self, attr1, attr2): self.attr1 = attr1 self.attr2 = attr2 self.attr3 = 42 3) What is with the __underscores__ ?? magic methods or attributes. The initializer ('__init__') is one of them, which is called at instance creation time. Most of the magic __methods__ are used to implement or override operators. You'll find the relevant documentation around here: http://docs.python.org/ref/specialnames.html 4) Are parameters passed to an class definition? class Whatever(params): pass A class statement is not a function definition statement. Here, you ask for a class Whatever inheriting from class params. Cf the above point about the __init__ method for passing args at instanciation. I sort-of understand the way objects work with PHP. With PHP, the classes are defined in one place - sort of like a function. FWIW, Python's classes actually are callable objects (just like functions are callable objects). To instanciate a class, you just call the class, no 'new' keyword needed. To me, that makes more sense. ?php class Obj { // pass } $obj = new Obj(); $obj-name = toto; echo $obj-name; ? Just like Python (and Javascript FWIW), PHP objects are mostly hashtable in disguise. But - having some experience with both PHP and Python (and some other OOPLs), I can tell you that Python's object model is far superior to PHP's one. The only gotcha here wrt/ most other object models is that attributes defined in the class statement body (ie, outside methods) are attached to the class object itself (and then shared by all instances of the class), not to instances themselves. Instance attributes initialisation is usually done in the __init__(self, ...) method. HTH -- bruno desthuilliers python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Thanks everybody. I will sort all of this out, but right now my head is spinning. Is there some book, or other reference, that explains of this? I was thinking about Python for Dummies. The Think like a Computer Scientist book, and Dive into Python book don't seem to explain Python's object model clearly enough for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
walterbyrd [EMAIL PROTECTED] writes: Is there some book, or other reference, that explains of this? I was thinking about Python for Dummies. The Think like a Computer Scientist book, and Dive into Python book don't seem to explain Python's object model clearly enough for me. The canonical introduction is the Python tutorial:: URL:http://docs.python.org/tut/ To get benefit from this, you should *work through* this document, not merely read it. Do each exercise and don't go on until you believe you understand what it's doing. -- \ When I turned two I was really anxious, because I'd doubled my | `\ age in a year. I thought, if this keeps up, by the time I'm six | _o__) I'll be ninety. -- Steven Wright | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Ben Finney wrote: Or, the attributes are added to a specific instance (often in the initialisation method) so that each instance has a separate attribute with the same name:: class Point(object): spam = 4 def __init__(self): eggs = 2 There's a typo there. For the sake of not confusing the OP, this is correct: class Point(object): spam = 4 def __init__(self): self.eggs = 2 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
walterbyrd [EMAIL PROTECTED] writes: Reading Think Like a Computer Scientist I am not sure I understand the way it describes the way objects work with Python. Congratulations for taking the effort to figure it out, and for thinking about the questions you want answered. 1) Can attributes can added just anywhere? I create an object called point, then I can add attributes any time, and at any place in the program? Generally, yes. It's up to the programmer to do so in a way that's readable and makes sense to later readers. There are conventions, of course, and you should ask about anything specific that confuses you. One convention that you seem to be unaware of is that assigning attributes outside of the class's methods is unusual. This is only a convention, though, and not enforced by the language; on the uncommon occasions you need to add attributes to an instance outside that class's methods, you're not prevented from doing it. 2) Are classes typically created like this: class Point: pass Typically, classes are created as a subclass of another class. The top-level basic type in Python is 'object', so if your class doesn't make sense deriving from anything else, derive from 'object'. class Point(object): pass Defining a class with *no* superclass is not recommended. If you don't yet understand the difference between the above style (called a new-style class) and the style you presented, you should always derive from a superclass ('object' or something more specific) until you encounter a situation where that causes a problem. Then attributes are added at some other time? No. Typically, the desired attributes are added either to the class when it is defined, resulting in an attribute value that is shared by all instances of that class:: class Point(object): spam = 4 Or, the attributes are added to a specific instance (often in the initialisation method) so that each instance has a separate attribute with the same name:: class Point(object): spam = 4 def __init__(self): eggs = 2 3) What is with the __underscores__ ?? Another convention. Names of the form '__foo__' are a signal to the reader that this name will be treated specially; often the internals of Python syntax or some builtin type will look for those names when performing behind-the-scenes magic. For instance, the '__init__' attribute of a class is expected to be a function, and that function is called by Python's instance creation steps immediately after the creation of an instance. Thus, it is used to initialise the newly-created instance of the class, doing things specific to that instance. 4) Are parameters passed to an class definition? class Whatever(params): pass The parameters of the class definition are the super-classes from which this class should inherit its attributes. They don't correspond with the parameters to the class constructor. When you create a new instance of a class, its constructor is called to create the new instance, and then the initialiser is called, to perform post-creation steps on the new instance. This all occurs in one step, as far as the code that called the constructor is concerned. Unlike in many other languages, you will rarely need to define a constructor ('__new__') for your Python classes. It's far more common to let the default constructor create the object, and have any initialisation steps on the newly-created instance performed in the class '__init__' method. The __init__ method gets called by Python's internals (hence the special name with underscores) immediately after the creation of the instance. It is called with parameters consisting of the newly-created instance object, followed by all the parameters that were passed to the constructor. origin = Point(0, 0) This will call the constructor of the Point class, which will create a new instance; then, the __init__ method of the Point class will be called with the parameters (new Point instance, 0, 0). This means the function has access to the specific instance, and can modify it accordingly. The convention is to use 'self' as the name to refer to the first parameter to instance methods, so that the instance object is referred to by the parameter name 'self' in that method. class Point(object): spam = 4 def __init__(self, x_coord, y_coord): if x_coord 0: x_coord = 0 if y_coord 0: y_coord = 0 self.x = x_coord self.y = y_coord This initialisation method does a bit of value fudging, then assigns values to attributes of the instance, named 'self' in the context of the method. After the constructor and the __init__ method have finished, the program continues at the point where the constructor was called. Thus, the attributes assigned to the instance are immediately available:: origin = Point(0, 0) print origin.x -- \ Anyone who believes
Re: Trying to understand Python objects
James Stroud wrote: walterbyrd wrote: Reading Think Like a Computer Scientist I am not sure I understand the way it describes the way objects work with Python. 1) Can attributes can added just anywhere? I create an object called point, then I can add attributes any time, and at any place in the program? Not all objects behave this way. For example, incidences of the object class: (snipped) Then attributes are added at some other time? Yes. This goes for old (clasobj) and new style classes. (snipped) I think this flexibility is part the python philosophy, but I am not a python philosopher (nor was I meant to be). Neither a python tutor, apparently, but strong candidate for the monthly most confusing-to-a-newbie reply award. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to understand Python objects
Ben Finney [EMAIL PROTECTED] writes: Or, the attributes are added to a specific instance (often in the initialisation method) so that each instance has a separate attribute with the same name:: The example here should have been:: class Point(object): spam = 4 def __init__(self): self.eggs = 2 -- \ For mad scientists who keep brains in jars, here's a tip: why | `\not add a slice of lemon to each jar, for freshness? -- Jack | _o__) Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list