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

Guido van Rossum guido at python.org
Tue Jan 16 18:50:59 CET 2007

On 1/16/07, Phillip J. Eby <pje at telecommunity.com> wrote:

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: * Don't remove any feature for which an alternative doesn't already exist in 2.5

Without specific features named I don't understand what this means.

* Don't change APIs (e.g. items())

That's a non-starter. "Don't change APIs" means essentially nothing can be changed.

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.

Let's have that discussion on the py3k list. We went through that and I definitely don't want them to be just attributes (it was proposed several times before). I'd be happy to come up with a rationale, but not here.

Then, we could provide that feature in 2.6, and drop the availability of the callable forms in 3.0.

This is clearly an example of constraining 3.0 in order to provide better compatibility, which is a contradiction of 3.0's very existence.

[...]

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.

Actually it's very easy to write code using keys(), items() and values() that works as well in 2.2 as it works in 3.0: never use the iter* variants, and don't sweat the performance costs of creating a list so much. If you can't afford to create a list, iterate over the dict itself, which will give you the keys in both versions.

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.

I'm not aware of compromises to 3.0's architecture that were made in order to ease the transition though -- all of the burden was placed on Zope 2.x (though perhaps some optional compatibility packages were also added to Zope 3.0?).

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.

Such analogies are hard to get right; in this case he's talking about file interchange formats. Perhaps the closest analogy is pickling. AFAIK pickles are exchangeable between the two now; if at some point they grow apart, it shouldn't be too hard to add a new default pickling protocol to 3.0 and add support for it to 2.6.

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

More information about the Python-Dev mailing list