Why is there no natural syntax for accessing attributes with names not being valid identifiers?
tjreedy at udel.edu
Thu Dec 5 03:58:23 CET 2013
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
>> (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
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
Terry Jan Reedy
More information about the Python-list