Eric Smith wrote:
This code works on 2.6 and 3.0:
>>> format(1+1j, '10s')
'(1+1j) '
That's because format ends up calling object.__format__ because complex
doesn't have its own __format__. Then object.__format__ calls str(self)
which returns '(1+1j) '. So the original call basically turns into
"format('(1+1j) ', '10s')".
Guido pointed out this should have been:
"""That's because format ends up calling object.__format__ because
complex doesn't have its own __format__. Then object.__format__ calls
str(self) which returns '(1+1j)'. So the original call basically turns
into "format('(1+1j)', '10s')".""" (I had inserted the spaces added by
str.__format__ too early.)
We discussed this at the sprint.
We agreed that we'd just allow this specific issue with complex
formatting to possibly break existing uses in 2.7, as it did in 3.1.
While that's unfortunate, it's better than the alternatives.
The root cause of this problem is object.__format__, which is basically:
def __format__(self, fmt):
return str(self).__format__(fmt)
So here we're changing the type of the object (to str) but still keeping
the same format string. That doesn't make any sense: the format string
is type specific. I think the correct thing to do here is to make it an
error if fmt is non-empty. In 2.7 and 3.2 I can make this a
PendingDeprecationWarning, then in 3.3 a DeprecationWarning, and finally
make it an error in 3.4.
Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
