Feature request: String-inferred names
pavlovevidence at gmail.com
Mon Nov 30 04:52:44 CET 2009
On Nov 26, 3:43 pm, The Music Guy <music... at alphaios.net> wrote:
> 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.
This transformation isn't possible in Python. Python has seperate
compile and run times, and the value of a variable (like foo) isn't
known at compile time, but it would have to be known at compile time
for the interpreter to "see" the value of that variable ("bar" in this
Therefore, to get the effect you want, the evaluation of foo would
have to be delayed until run time. The interpreter would "see" $foo,
and explicitly change it to bar. But that leads to another problem.
Local variables (in CPython at least) are converted to index lookups
during the compile phase, for efficiency reasons. Python doesn't use
the name of a the local variable at run time at all, and you can't
dynamically create local variables. Thus, to use your syntax proposal
with local variables you would have to accept two concessions:
1. You could not use $foo to dynamically create a new local variable;
foo would have to evaluate to the name of a local variable that
2. You would take a significant performance hit.
Furthermore, this would introduce a bad analogical inconsistency into
the language. If you can write foo.$bar=1 to create a new attribute,
you'd expect to be able to write $bar=1 to create a new local
variable, but you can't.
These issues are significant, and given that a proposal for just
computed attributes that didn't have these issues was already
rejected, I would say your proposal would have absolutely no chance,
even if there hadn't been a moratorium on new syntax.
More information about the Python-list