[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