[Python-ideas] of properties and metaclasses

[Ron Adam]

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 
descriptors.

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.)

Cheers,
    Ron