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.

Reply via email to