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

rusi rustompmody at gmail.com
Wed Dec 4 11:09:37 CET 2013


On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote:
> On Tue, Dec 3, 2013 at 11:31 PM, rusi  wrote:
> > Its a more fundamental problem than that:
> > It emerges from the OP's second post) that he wants '-' in the attributes.
> > Is that all?
> >
> > Where does this syntax-enlargement stop? Spaces? Newlines?
>
> At non-strings.
>
> >>> setattr(foo, 21+21, 42)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: attribute name must be string, not 'int'

Not sure what's your point. 

OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field.
Say I have a python expression: 
obj.outer_fieldset-inner_fieldset-third_field

It can (in the proposed extension) be parsed as above, or as:
obj.outer_fieldset - inner_fieldset-third_field
the first hyphen being minus and the second being part of the identifier.

How do we decide which '-' are valid identifier components -- hyphens
and which minus-signs?

So to state my point differently:
The grammar of python is well-defined
It has a 'sub-grammar' of strings that is completely* free-for-all ie just
about anything can be put into a string literal.
The border between the orderly and the wild world are the quote-marks.
Remove that border and you get complete grammatical chaos.
[Maybe I should have qualified my reference to 'spaces'.
Algol-68 allowed spaces in identifiers (for readability!!)
The result was chaos]

I used the spaces case to indicate the limit of chaos. Other characters (that
already have uses) are just as problematic.

* Oh well there are some restrictions like quotes need to be escaped, no 
  newlines etc etc -- minor enough to be ignored.



More information about the Python-list mailing list