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

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

- Tal