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