[Python-3000] [Python-Dev] What should the focus for 2.6 be?

Jean-Paul Calderone exarkun at divmod.com
Mon Aug 21 23:38:17 CEST 2006

On Mon, 21 Aug 2006 14:21:30 -0700, Josiah Carlson <jcarlson at uci.edu> wrote:
>Talin <talin at acm.org> wrote:
>> I've been thinking about the transition to unicode strings, and I want
>> to put forward a notion that might allow the transition to be done
>> gradually instead of all at once.
>> The idea would be to temporarily introduce a new name for 8-bit strings
>> - let's call it "ascii". An "ascii" object would be exactly the same as
>> today's 8-bit strings.
>There are two parts to the unicode conversion; all literals are unicode,
>and we don't have strings anymore, we have bytes.  Without offering the
>bytes object, then people can't really convert their code.  String
>literals can be handled with the -U command line option (and perhaps
>having the interpreter do the str=unicode assignment during startup).

A third step would ease this transition significantly: a unicode_literals __future__ import.

>Here's my suggestion: every feature, syntax, etc., that is slated for
>Py3k, let us release bit by bit in the 2.x series.  That lets the 2.x
>series evolve into the 3.x series in a somewhat more natural way than
>the currently proposed *everything breaks*.  If it takes 1, 2, 3, or 10
>more releases in the 2.x series to get to all of the 3.x features, great.
>At least people will have a chance to convert, or at least write correct
>code for the future.

This really seems like the right idea.  "Shoot the moon" upgrades are
almost always worse than incremental upgrades.

The incremental path is better for everyone involved.  For developers of
Python, it gets more people using and providing feedback on the new
features being developed.  For developers with Python, it keeps the scope
of a particular upgrade more manageable, letting them developer focus on a
much smaller set of changes to be made to their application.


More information about the Python-3000 mailing list