On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/18/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > > [...]
> > > class C:
> > > x = property(._get_x, ._set_x, ._del_x,
> > > "This is the x property")
> > > [...]
> >
> > > This is slightly more Pythonic, and unambiguous, but I'd rather
> > > reserve leading dot for a more powerful feature, perhaps .foo as an
> > > abbreviation for self.foo, or some other scope-ish operator. (I also
> > > note that in a proportional font the . is easily missed.)
> > Does that conflict? Wouldn't self._get_x fall through to
> > self.__class__._get_x, which is exactly what you want? (Except that
> > you *might* the ability to override methods on a per-instance basis.)
> Not in this context. When the expression "property(._get_x, ._set_x,
> ...)" is evaluated, there is no self yet (unless it is an unrelated
> outer self).
Ah ... you were thinking of ._get_x as an expression which would be
evaluated at compile-time to produce an actual method.
I was still thinking of symbols, and reading ".name" as syntactic
sugar for "self.name", with the caveat that the translation was made
at runtime rather that compile-time.
Therefore
property(._get_x, ._set_x)
would be syntactic sugar for
def __getx(self): return self._get_x()
def __setx(self): return self._set_x()
property(__getx, __setx)
except that the __getx and __setx methods wouldn't be added to the
visible namespace, even in mangled form.
-jJ
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
