[Python-3000] symbols?

[Jim Jewett]

On 4/18/06, Guido van Rossum <guido at python.org> wrote:
> On 4/18/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 4/14/06, Guido van Rossum <guido at python.org> 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")
> > > [...]
> >
> > > 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