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

rusi rustompmody at gmail.com
Wed Dec 4 12:27:46 CET 2013

On Wednesday, December 4, 2013 4:03:14 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Dec 4, 2013 at 9:09 PM, rusi  wrote:
> > OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field.
> > Say I have a python expression:
> > obj.outer_fieldset-inner_fieldset-third_field
> I don't think so. What the OP asked for was:
> my_object.'valid-attribute-name-but-not-valid-identifier'
> Or describing it another way: A literal string instead of a token.

This is just pushing the issue one remove away.
Firstly a literal string is very much a token -- lexically.
Now consider the syntax as defined by the grammar.

Let Ident = Set of strings* that are valid python identifiers -- 
something like [a-zA-Z][a-zA-Z0-9]*

Let Exp = Set to strings* that are python expressions

* Note that I am using string from the language implementers pov not language
user ie the python identifier var is the implementers string "var" whereas
the python string literal "var" is the implementer's string "\"var\""

Now clearly Ident is a proper subset of Exp.

Now what is the proposal?
You want to extend the syntactically allowable a.b set.
If the b's can be any arbitrary expression we can have
var.fld(1,2) with the grammatical ambiguity that this can be
(var.fld)(1,2)   -- the usual interpretation
var.(fld(1,2)) -- the new interpretation -- ie a computed field name.

OTOH if you say superset of Ident but subset of Exp, then we have to determine
what this new limbo set is to be. ie what is the grammatical category of 
'what-follows-a-dot' ??

Some other-language notes:
1. In C there is one case somewhat like this:
#include "string"
the "string" cannot be an arbitrary expression as the rest of C.  But then this 
is not really C but the C preprocessor

2. In lisp the Ident set is way more permissive than in most languages -- 
allowing operators etc that would be delimiters in most languages.
If one wants to go even beyond that and include say spaces and parenthesis -- 
almost the only delimiters that lisp has -- one must write |ident with spaces|
ie for identifiers the bars behave somewhat like strings' quote marks.
Because the semantics of identifiers and strings are different -- the lexical
structures need to reflect that difference -- so you cannot replace the bars
by quotes.

More information about the Python-list mailing list