Feature request: String-inferred names

[The Music Guy]

On Nov 26, 12:30 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Wed, 25 Nov 2009 23:35:06 -0300, The Music Guy  
> <FearsomeDragon... at gmail.com> escribió:
>
> > I just posted to my blog about a feature that I'd like to see added to
> > Python. Before I go through the trouble of learning how to write a PEP or
> > how to extend the Python interpreter, I want to know what people in the
> > community have to say about it.
>
> >http://alphaios.blogspot.com/2009/11/python-string-inferred-names-wor...
>
> > As far as I know, a feature like this does not appear in any existing  
> > PEPs.
> > (If it does I would appreciate it if someone could tell me what PEP it  
> > is.)
>
> Already suggested, and rejected; see PEP 363:  http://www.python.org/dev/peps/pep-0363/and the python-dev discussion.
>
> --
> Gabriel Genellina

Thank you for pointing that out. The PEP actually proposed some code
that I can use in my current project to help make it more readable:

        class attrs:
           def __init__(self, obj):
             self.obj = obj
           def __getitem__(self, name):
             return getattr(self.obj, name)
           def __setitem__(self, name, value):
             return setattr(self.obj, name, value)
           def __delitem__(self, name):
             return delattr(self, name)
           def __contains__(self, name):
             return hasattr(self, name)

That aside, I still feel that a new syntax would be a better solution
than a new class. And, anyway, what I'm proposing isn't *quite* the
same as what Ben North proposed. Ben's idea was *strictly* to create
shorthand syntax to the getattr/setattr/delattr in the context of
specific objects. What I'm suggesting could be more accurately
described as a namespace-neutral transformation of the value of an
expression into a name. So if "bar" is the value of foo, then when the
interpreter sees  $foo, it reads bar. And when the interpreter sees
obj.$foo, it reads obj.bar. It can effectively be used in the same way
as Ben's proposal, but also for names in the current scope.

Next thing is, I can't see logically how the path of the discussion of
the proposal lead to the proposal being rejected. It looked like a lot
of people really liked the idea--including Guido himself--and several
examples were given about how it could be useful. The final verdict on
the matter just doesn't make logical sense in the context of the
discussions.

The main problem that people had with it was more to do with the
syntactical form than with the feature itself, but that's easily
adjusted. Not to sound pompous (ahem), but the syntax that I propose
does not suffer from the problems that people had with other
suggestions, i.e. it looks less like a typo (how often do you
accidentally type a "$" when you meant to type a "(" or a "." ?), it
does not get easily confused as a function call, or indexing syntax,
or an ordinary member lookup, because none of those things rely on the
$ as an operator. Nothing does.

As for it not being useful enough to justify new syntax, well, I think
Ben showed pretty well that it actually is. Approximately 600 uses of
the get*r functions were used in the Python 2.5 standard library
alone. Now 2.7 is around the corner and that number has probably
grown, if only a little bit. Besides that, as I already stated in the
blog, a feature like this would make metaclassing code that generates
properties and methods much easier to write and understand.

Nonetheless, the fact remains that the feature I'm proposing closely
resembles one that has already been rejected... Well, it's been a few
years since then. Maybe its about time for another PEP to be proposed?