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

[Terry Reedy]

On 12/4/2013 3:46 PM, Mark Lawrence wrote:
> On 04/12/2013 20:35, Piotr Dobrogost wrote:
>> On Wednesday, December 4, 2013 2:06:44 AM UTC+1, Tim Chase wrote:
>>>
>>> I think random832 is saying that the designed purpose of setattr()
>>> was to dynamically set attributes by name, so they could later be
>>> accessed the traditional way; not designed from the ground-up to
>>> support non-identifier names.  But because of the getattr/setattr
>>> machinery (dict key/value pairs), it doesn't prevent you from having
>>> non-identifiers as names as long as you use only the getattr/setattr
>>> method of accessing them.
>>
>> Right. If there's already a way to have attributes with these
>> "non-standard" names

Fact.

>> (which is a good thing)

Opinion, not universally shared by developers, or 'good thing only as 
long as kept obscure'.

 >> then for uniformity with dot access to attributes with "standard" names

In a later post (after you wrote this) I explained that standard names 
are not always accessed with a dot, and that uniformity is impossible.

 >> there should be a variant of dot access allowing to access
 >> these "non-standard" named attributes, too.

More opinion. I am sure that I am not the only developer who disagrees.

> The obvious thing to do is to either raise this on python ideas, or if
> you're that confident about it raise an issue on the bug tracker with a
> patch, which would include changes to unit tests and documentation as
> well as code, get it reviewed and approved and Bob's your uncle, job
> done.

I think the latter would be foolish. Syntax changes have a high bar for 
acceptance. They should do more than save a few keystrokes. Use of new 
syntax makes code backward incompatible. New or changed Python modules 
can be backported (as long as they do not use new syntax ;-) either 
privately or publicly (on PyPI).

3.2 had no syntax changes; 3.3 one that I know of ('yield from'), which 
replaced about 15-20 *lines* of very tricky code;  3.4 has none that I 
can remember.

-- 
Terry Jan Reedy