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')".
In 3.1 (released) and 2.7 (not yet released) I implemented __format__ on
complex. So now that same code is an error:
>>> format(1+1j, '10s')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'complex'
That's because complex._format__ doesn't recognize string formatting
codes, in particular 's'.
There's a general problem that types that sprout __format__ will break
existing usages of format() that use some string formatting codes,
unless the types recognize string formats in addition to their own. I
think we should change the documentation of format() to warn that you
should really call str() on the first argument if you're relying on the
second argument being a string formatting code.
But what to do about 3.1 and 2.7 with respect to complex? I see 2 options:
1. Leave it as-is, such that 3.1 and 2.7 might break some uses of
format(complex, str).
2. Modify format to understand 's' and do the conversion itself. But we
don't do this for int and float, that's why we added '!s'.
I'm sort of leaning toward #1, but I'd like to know if anyone has an
opinion. I haven't heard of anyone complaining about this yet; it would
only have tripped up people moving from 3.0 -> 3.1, or from 2.6 -> 3.1
who used format (or str.format()) while specifying 's' or some other
str-specific format codes.
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
