Mark Dickinson <dicki...@gmail.com> added the comment:

I (reluctantly) agree it's surprising that "{0[-1]}".format(args) fails.  And I 
suppose that if it were allowed then it would also make sense to consider 
"{-1}".format(*args) as well, in order to preserve the equivalence between 
"{n}".format(*args) and "{0[n]}".format(args).  And then:

>>> "{-0}".format(*['calvin'], **{'-0': 'hobbes'})
'hobbes'

would presumably produce 'calvin' instead of 'hobbes'...

On '+': if "{0[-1]}" were allowed, I'm not sure whether the "+1" in 
"{0[+1]}".format(...) should also be interpreted as a list index.  I don't 
really see the value of doing so apart from syntactic consistency: there are 
very few other places in Python that I'm aware of that accept 
-<one-or-more-digits> but not +<one-or-more-digits>.

FWIW, my overall feeling is that the current rules are simple and adequate, and 
there's no great need to add this complication.

I do wonder, though:

How complicated would it be to make "{0[1]}".format({'1':'foo'}) a bit magical? 
 That is, have the format method pass an integer to __getitem__ if the 
corresponding format argument is a sequence, and a string argument if it's a 
mapping (not sure what the criterion would be for distinguishing).  Is this too 
much magic?  Is it feasible implementation-wise?

I don't think it's do-able for simple rather than compound field names: e.g.,  
"{0}".format(*args, **kwargs), since there we've got both a sequence *and* a 
dict, so it's not clear whether to look at args[0] or kwargs['0']. (Unless 
either args or kwargs is empty, perhaps.)  This is all getting a bit 
python-ideas'y, though.

BTW, I notice that PEP 3101's "Simple field names are either names or numbers 
[...] if names, they must be valid Python identifiers" isn't actually true:

>>> "{in-valid #identifier}".format(**{'in-valid #identifier': 42})
'42'

Though I don't have a problem with this;  indeed, I think this is preferable to 
checking for a valid identifier.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to