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

Phillip J. Eby pje at telecommunity.com
Tue Jan 16 18:06:12 CET 2007

At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:

On 1/16/07, James Y Knight <foom at fuhm.net> wrote: > On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote: > > There seems to be rather a lot of confusion. No one is suggesting > > Python 3.0 be anything less for the sake of backward compatibility. > > Instead, it has been suggested Python 2.6 (and possibly 2.7) be > > something more in order to provide for an easier upgrade path. No > > compromises in Python 3.0. > > True: nobody is suggesting python 3.0 be anything less. But, I am > indeed suggesting that Python 3.0 be something more: I am > suggesting that people keep in mind the ease of writing of a program > which can run on both 2.5 and 3.0. And wherever possible, act so as > to preserve that ease. That may indeed involve a "compromise" in 3.0.

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 think what he's saying boils down to two things:

Now, I'm not sure these goals are achievable with respect to 2.5. I think we'd be better off adding compatibility features in 2.6.

To be honest, the items() and keys() thing personally baffles me. If they're supposed to be views on the underlying dictionary, wouldn't it make more sense for them to be attributes instead of methods? I.e. dict.items and dict.keys. Then, we could provide that feature in 2.6, and drop the availability of the callable forms in 3.0.

Then you could write code like:

 for k,v in somedict.items:
     ...

And have it work in 2.6 and 3.0. Meanwhile, .items() would still return a list in 2.6 (but be warnable about with a -3 switch), but go away entirely in 3.0.

It's not a panacea, but at least would make it possible to write code that runs on both 3.0 and some 2.x version.

Without having at least some 2.x version that can run 3.x code, I think there is little chance of 3.0 becoming viable. You've been comparing this to Zope 2/Zope 3, but in that world there is something called "Five" that lets you do Zope 3 things inside of Zope 2, so you have some chance of porting your code in an incremental fashion, without having to leap everything over in one go.

You've cited JoS on your decision not to do 3.0 as a ground-up rewrite, so perhaps you'll find this other JoS article relevant here:

"""It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn't want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you're the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can't switch until you can participate in the 123 ecology."""

http://www.joelonsoftware.com/articles/fog0000000052.html

The analogy isn't perfect, because we are not so much trying to provide backward compatibility in "Excel" as to add forward compatibility to "123", but you get the idea.

More information about the Python-Dev mailing list