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. -- https://mail.python.org/mailman/listinfo/python-list
