On Jun 16, 11:35 pm, Micky Hulse <rgmi...@gmail.com> wrote: > > >> def get_separator(self): > >> return ' :: ' > > In this case (returning a constant), it would be much simpler to make > > it a class (or instance) attribute. > > Ah, I think I get it. > > Just to clarify things for me, does attribute equal a property or method? :D
Python's object model is a bit peculiar (wrt/ most OOPLs at least), and I won't start to explain it here (this would require a full book FWIW). To make a long story short, you have class and instance attributes, and since a small code snippet can say more than a thousand words: class Foo(object): bar = 42 # this a class attribute def __init__(self, yoot): self.yoot = yoot # this is an instance attribute # this is an instance method def baaz(self): print "%s.baaz" % self # this is a class method @classmethod def yuu(cls): print "%s.yuu" % cls > I am guessing that attribute = property Nope. "property" is a builtin Python class that implements the descriptor protocol and give support for simple computed attributes. > @property > def separator(self): > return ' :: ' This is even more overkill. In Python, if all you need is a plain attribute, just use a plain attribute - you can transparently turn it into a computed one later if needed so no need to waste time with getters/setters. > > Properties are for computed attributes - that is, things that are the > > semantically (conceptually, whatever) attributes, but requires any > > computation, either on get, set or del. > > Ah, interesting... I think I need to let this all sink in a little. :) > > > But well, if you prefer java- > > like getters/setters, then choice is yours... Depends on the > > programmer's background, > > I have a little experience with Actionscipt 3 and PHP5 OOP... I guess > I am used to the concept/practice of getters/setters, > (public/private/other) class methods and properties. Warning: in Python, a "class method" is a method that can be called either on the class or instance, AND takes the class as first argument. "ordinary" methods - the ones that takes the instance as first argument - are also called "instance methods". wrt/ "public/private", there's no such thing in Python anyway. The (*very* strong) convention is to prefix implementation stuff with a single leading underscore which means "don't touch or your on your own if something breaks", but nothing prevents client code to mess with some object's internals. > Are you saying that a non-property model class method is equivalent to > getter/setter? No. > Or, maybe you are saying that the "lat = > property(_get_lat)" python property syntax is like > getters/setters/accessors in other programming langs? Mostly, yes - with the exception that since Python can let you turn a plain attribute into a computed one without breaking client code, you don't have to use getters / setters "just in case" - you only use them if and when needed, and encapsulate them into a property (or a custom descriptor) so the client code don't have to care. > Again, sorry if stupid questions... sorry if this is getting OT for > the Django list. Well, I usually redirect this kind of questions to c.l.py, since it's about Python and not Django... > > and of course of whether the code was written > > before new-style classes and the descriptor protocol.... > > I have not heard of this before. Googling "new-style classes and the > descriptor protocol" now. ;) Warning: this (and metaclasses) can be a bit mind-bending at first, and tend to become highly addictive once you get it ;) If I may suggest another related reading: http://wiki.python.org/moin/FromFunctionToMethod FWIW, Django relies quite a lot on metaclasses and descriptors for the ORM part. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.