[Python-Dev] The bytes type

Guido van Rossum guido at python.org
Tue Jan 16 20:35:00 CET 2007


On 1/16/07, James Y Knight <foom at fuhm.net> wrote:
> On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:
> > I'm not keen on compromises in 3.0, but without specific proposals I
> > don't see why we're arguing. So, please, what specific thing(s) are
> > you proposing we do in 3.0? Please make a list of specifics rather
> > than attempting at specifying a general rule to match things that
> > could go into the list; you've tried the latter and I still don't know
> > what you want.
>
> I can't come up with a full list, as I don't know everything that's
> changed or is being planned to change. But here's some stuff I do
> know about:
>
> 1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys
> 2) For the bytes type, keep enough of an overlap with the current use
> of str-as-raw-bytes that common operations work with either one (so
> that I can, f.e. read from a socket or a file and process that data).
> Without seeing the details for how bytes is going to be implemented,
> it's hard to say exactly what this means.
> 3) Preferably continue to allow old syntax when adding new syntax
> (e.g. exception catching syntax). Alternatively, a completely
> reliable automated conversion script to convert the syntax would also
> be acceptable if not quite as convenient.
>
> Mainly I'd just like to see "allowing the ability to write code which
> is portable between 2.5 and 3.0" as an explicit goal of the python
> 3.0 release. I trust that if the developers agree upon that as being
> a goal, the right things would happen, whatever they may be for the
> specific change in question.

Well, there's the crux. That is an explicit NON-goal. It always has
been. It would add tons of constraints to Python 3000, and the net
effect would be that everybody would continue to code in the 2.5
dialect, making the intended cleanup of the language ineffective.

We are planning various other ways of providing conversion help. The
most promising at this point is to make the following an explicit goal
of Python 2.6 and Python 3000: make it possible to write code that
runs under 2.6, and that, after automatic conversion using the 2to3
refactoring tool (see sandbox/2to3), runs under 3.0, *without*
requiring manual patching up of the output of the refactoring tool.

The latter clause makes it easy (if not trivial) for developers to
maintain parallel versions. All you need is a sufficiently good test
suite, so that you can automatically verify that the conversion result
actually works as intended under 3.0. Since you'd have to do that
testing anyway, there is not much of an added effort except for
maintaining separate tarballs.

There are still certain things you can't do, because the conversion
tool doesn't handle them well (e.g. don't use variables named 'long'
and don't create classes with methods named 'keys'); but I expect that
the subset of 2.6 that you can use will be much larger using this
approach than what you would get using the identical-source approach
you are supporting.

Oh, and the same approach will also work (with only a few more
constraints) for 2.5 and even earlier versions.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list