[Python-Dev] SF:1463370 add .format() method to str and unicode (original) (raw)

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.

SF:1463370

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 account.

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-Dev mailing list