[Python-3000] symbols?

Ian Bicking ianb at colorstudy.com
Fri Apr 14 19:09:58 CEST 2006


Guido van Rossum wrote:
> Then, on 4/14/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> [...]
> class C:
>   x = property("_get_x", "_set_x", "_del_x",
>                "This is the x property")
> [...]
> 
> (BTW I thought I implemented this but can't find any evidence.)

Name conventions are a bit bothersome to me, but then explicit names 
like this are even more bothersome.  Anyway, I might imagine:

   x = property('x')
   def x__get(self): ...
   def x__set(self): ...
   def x__del(self): ...

Where the __get/__set/__del versions are all implied simply by 'x'. 
(I've come to prefer x__* over _*_x, because it doesn't clash with the 
notion of private, but still looks obviously magic)

Even better, though, would be:

   x = property()

Where it just magically knew that it was being called 'x'.  This is what 
I have done in SQLObject (and is done similarly in several other ORMs) 
using metaclass futzing, where on class instantiation you check every 
class variable to see if it is interested in its name and what class it 
is bound to.  PEP 359 (the 'make' syntax) addresses this to a degree, 
since you can do:

   make property x: ...

And it intrinsically knows its name.  Which is no longer important if 
the property *contains* the items.  In fact, this might indicate a flaw 
or other problem with the syntax; or maybe it just means that it should 
be extended to a non-block form, so you can say *just*

   make property x

And it is invoked with an empty dictionary.  Hrm.

As another use case is a set-once attribute.  This is basically a 
read-only attribute in descriptor form, but set once, since read-only is 
useless if you can't write to at least once in __init__ ;)  You can do 
that just with descriptors right now, but it doesn't work well because 
the descriptor doesn't know its name.  Because it doesn't know its name 
the descriptor has to store its value in an arbitrary attribute.  Once 
that has happened, the object is essentially unpickleable.

I describe the descriptor here:
   http://blog.ianbicking.org/easy-readonly-attributes.html
and the problem here:
   http://blog.ianbicking.org/descriptor-nit.html

Again, while it wants to know its name, it doesn't have any "body", and 
so PEP 359 as it is doesn't quite address the problem.

This doesn't address any of the issues of a descriptor knowing what 
*class* it is bound to, only what name.  But I've found the class part 
to be much more difficult than the name, due to subclassing.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Python-3000 mailing list