[Python-ideas] of properties and metaclasses

Ron Adam rrr at ronadam.com
Tue Jul 24 18:25:44 CEST 2007

Tal Einat wrote:
> On 7/24/07, *Ron Adam* <rrr at ronadam.com <mailto:rrr at ronadam.com>> wrote:
>      >> The same object in a class might look like...
>      >>
>      >> property foo(self):
>      >>     self.__value__ = None
>      >>     def __get__(self):
>      >>         return self.__value__
>      >>     def __set__(self, value):
>      >>         self.__value__ = value
>      >
>      > In the first version, how is anything supposed to know that
>      > the __value__ inside the function is an implicit attribute
>      > of self rather than a local variable of the function
>     In the first example self isn't implicit, it's non-existent.  It
>     would work
>     more like a generator that yields it value on gets, and receives its
>     value
>     on sets.
>     In the second version self is passed to the functions explicitly so
>     it can
>     work in an instance.  But other than that it's the same.  It could also
>     keep state between calls, in which case all instances of that class
>     would
>     share those values.  (just like instances share class attributes)
>        class bar(object):
>           property foo(self):
>               countgets = 0
>               self.__value__ = None
>               def __get__()
>                   countgets += 1
>                   return countgets, self.__value__
>               def __set__(value)
>                   self.__value__ = value
>     In this case countgets will be the total gets of all subclasses of bar.
>     This could be done with a class attribute as well, but that breaks
>     the idea
>     of having a single self contained component.  Having self contained
>     components is more conducive to a modular design where you can more
>     easily
>     reuse parts.
> Pardon me for interrupting... 

You aren't interrupting at all, but adding to it.  ;-)

> Don't the existing descriptors do all of 
> this, with almost exactly the same syntax? You just have to set a class 
> variable to an instance of the descriptor class, which is one extra line 
> of code. Additionally, this allows reuse of a descriptor class for 
> multiple properties, which as-far-as-I-can-tell your models don't.

Yes you are correct and it is why I said at the beginning one of the 
problems is you can't make a lot of these without resorting to meta 
programming techniques.

> Perhaps I'm missing something, but I can't see the actual benefit of 
> your suggestions (besides inline-ing of properties' names).

Inline-ing property names isn't really the point at all.  A much bigger 
change is having a way to use them outside of classes for indirect references.

     foo = ['a', 'b', 'c', 'd']

     property thirdfoo():
        def __get__():
            return foo[3]
        def __set__(value):
            foo[n] = value

     print thirdfoo     --->  'c'
     thirdfoo = 'z'     # Doesn't rebind thirdfoo to 'z'!
     print thirdfoo     --->  'z'
     print foo          --->  ['a', 'b', 'z', 'd']

Now as far as re-use goes, it could be more like a class with an __init__ 
method. Then it becomes almost exactly like the current descriptor objects 
too. (Maybe a good thing.)

The reason 'class' is replaced by 'property' is that it needs some way to 
tell the interpreter that this has different access characteristics than a 
normal name/object binding so it can be used outside of a class.

That change (potentially) makes descriptors/properties independent from the 
classes they are in.

Another way to do it might be to have a indirect name space.  Then it 
becomes a matter of moving a class (or suitable function) to "indirect" to 
activate it as a local descriptor.  Or "__indirect__" in the case of class 

And yes this is still a rather abstract idea.  The question is would it be 
beneficial to generalize and formalize descriptors and properties? (but not 
necessarily in the exact manner I'm describing.)


More information about the Python-ideas mailing list