[Python-3000] [Python-Dev] SF:1463370 add .format() method to str and unicode
Guido van Rossum
guido at python.org
Mon Apr 3 20:40:42 CEST 2006
On 4/3/06, Crutcher Dunnavant <crutcher at gmail.com> wrote:
> >From discussion on python-3000, it occured to me that this shouldn't
> break anything.
> This patch adds a .format() method to the string and unicode types.
Hmm... Let's not jump to conclusions. While I like your patch, we need
to have community consensus that s.format(x) is better than s%x, and
we need to discuss alternatives such as a different format syntax.
I guess I have to amend my process proposals (and yes, I know it's
high time for me to get back on the wagon and start spending quality
time with Python 3000). While I still believe that new features which
can be introduced without backwards incompatibility are fair game for
introduction in Python 2.x rather than waiting for 3.0 (and in fact,
introduction in 2.x is perhaps preferable over waiting), the realities
of community opinion and proposal history need to be taken into
We also, in particular, need to be really careful that we don't
introduce things into 2.x that we *think* we'll want in Py3k but which
might turn out later to require more tweaks. For example, in the case
of the formatting method, it would be tragic if Python 3000 switched
to a different format syntax but we had already introduced s.format(x)
in Python 2.x as an alias to s%x -- then the meaning of s.format(x)
would change in Python 3000, while we might have had the opportunity
of a 10)% *compatible* change if we had waited until the Python 3000
version of the feature had settled before rushing it into Python 2.x.
Concluding, perhaps the right time to include certain features in
Python 2.x is only *after* the feature has been discussed, specified,
agreed upon, and implemented in Python 3000.
Of course, this doesn't mean we shouldn't plan to add anything new to
Python 2.x (even though that would greatly reduce merge problems with
the Py3k branch ;-). I guess changes to 2.x should follow the
established, 100% backwards compatible, evolutionary path: if
python-dev agrees it's a good idea, it should probably go in. OTOH if
it's a potentially disruptive change, or if it could benefit from
synchronicity with other Py3k features, or perhaps even if it just
adds a new way of saying something that might eventually mean the old
way should be deprecated, it's better to refine the idea in a Python
3000 context first.
It's going to be inevitable that we'll get the occasional idea first
brought up on python-dev that makes more sense to move to Python 3000,
or vice versa; let's all be mindful of such cases.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000