Why is there no natural syntax for accessing attributes with names not being valid identifiers?

Terry Reedy tjreedy at udel.edu
Wed Dec 4 17:11:56 EST 2013


On 12/4/2013 3:07 PM, Piotr Dobrogost wrote:

You have proposed to make non-identifier attribute names 'official', 
rather than discouraged, by abbreviating
 > x = getattr(obj, 'value-1')
or
x = obj.__dict__['value-1']  # implementation detail
as
> x = obj.'value-1'

The discussion of enlarging the scope of 'identifier' is not relevant as 
you are not proposing that. In particular, you are not asking that 
obj.value-1 get the 'value-1' attribute of obj. The discussion of 
keystrokes is also a side-track.

What you are proposing, I believe, is a new grammatical category: 
attribute-name := identifier or string-literal. This would break the 
symmetry of the grammatical form identifier '.' identifier and change it 
to the asymmetrical identifier '.' attribute-name, and that is the 
problem.  Most identifiers are attributes of a namespace and many 
attributes are set *and accessed* as undotted names in module or class 
code.  The symmetry is at least partly inherent and breaking it does not 
work very well.

 >>> len is __builtins__.len
True
 >>> __globals__ = __import__(__name__)
 >>> a = 1
 >>> a is __globals__.a
True

To put it another way, how does 'obj' get the non-standard attribute 
'value-1', when obj is a module or class? The workaround given above for 
module attributes will not work for classes.

>> Remember the Python philosophy that there ought to be one way to do
>> it.
>
> Funny you use this argument against my idea as this idea comes from
> following this rule whereas getattr goes against it.

Not really. As others have pointed out, getattr is the preferred way to 
get the value of an attribute when you have an object with attributes 
and a run-time-only reference to the name in a string variable.

It would also be the case that "obj.'value' is obj.value", so the 
proposal *would* add duplication.

-- 
Terry Jan Reedy




More information about the Python-list mailing list