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

Thomas Wouters thomas at python.org
Tue Jan 16 20:33:42 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.

Actually, you missed the part where that is explicitly not the goal of Python 3.0. The main goal of Python 3.0 is explicitly to break the things you don't want broken. If you really not want them broken, Python 3.0 is a non-starter for you. You can basically stop worrying about it, and just never switch any of your Python 2.5 projects to Python 3.0. If you want to talk about an upgrade-path, you will have to accept that it means waiting for Python 2.6, and also that it means not using some features that will be removed, like the iter* methods of dicts. We (or at least some of us ;-) will do our best to provide a viable upgrade path from 2.6 even for complicated cases like the changing dict methods, but an upgrade path directly from 2.5-or-earlier to 3.0 is just plain impossible; you would have to change your code to avoid the things that will change in Python 3.0, which may lead to inefficient or complicated code.

Python 3.0 is there to break backward compatibility, and do it cleanly. Any work done to ease the upgrade path should be done in 2.x (and separate tools), not 3.0. 3.0 is not a transitional release.

-- Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070116/cf962af4/attachment.htm

More information about the Python-Dev mailing list