Feature request: String-inferred names

[Lie Ryan]

Brad wrote:
> On Nov 25, 10:49 pm, Chris Rebert <c... at rebertia.com> wrote:
>> On Wed, Nov 25, 2009 at 6:35 PM, The Music Guy
>>
>> <FearsomeDragon... at gmail.com> wrote:
>>> Hello all,
>>> 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.)
>>> Please give and comments you may have, but I request that you be
>>> constructive if you must criticize...thank you!
>> Ugly, Perlish, and as you even admit, entirely unnecessary.
>> And you'd need to wait at least a year anyway:http://www.python.org/dev/peps/pep-3003/
>>
>> Cheers,
>> Chris
>> --http://blog.rebertia.com
> 
> Like I said, lots of things in Python are "unnecessary," but that
> doesn't make them "useless," and it certainly doesn't mean they
> shouldn't exist. My proposed feature is not useless; I think it would
> make a lot of code easier.

How is it easier than using dictionary with string as keys? setattr, 
getattr, and delattr are already sugar for accessing instance.__dict__.

You make a comparison with decorators; even if it's unnecessary it does 
eliminate a DRY case (don't repeat yourself):
def foo(self): pass
foo = property(foo)

there you repeat foo three times unnecessarily, instead of:
@property
def foo(self): pass

people already bashed decorator syntax because it is ungoogleable; a 
non-python programmer reading a python code can't google "python @" to 
find out that it's a decorator. $ has very similar problem; and we don't 
want to add more of this wart.

You also make with iterators and generators. Iterator and generator is 
an implication of the core design of python; because python chose not to 
have a for-loop (python's "for-loop" is actually a for-each-loop). 
Without the iterator protocol, it is not possible to make an iterable 
class and people would have to use "for x in range(len(foo)):" every so 
often. Iterator protocol also makes it possible to have infinite 
iterable (e.g. for x in primegenerator(): produces prime numbers 
indefinitely).

A list comprehension is space saver; it saves a lot of lines for the 
very common operation:

a = []
for x in orig:
     if test(x):
         a.append(transform(x))

into one concise line:
a = [transform(x) for x in orig if test(x)]

Also a generator comprehension can be passed around without being evaluated.

As you see, these "unnecessary features" does have significant benefits 
to it. Decorators reduced DRY, iterators/generators eliminates the need 
of range-len for-loop, list comprehension is huge space saver.

The proposed syntax only saves a few character, does not eliminate any 
DRY, is ungoogleable, and looks confusing to me. Is there any 
significant benefit from it?