[Python-Dev] The bytes type (original) (raw)

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