[Python-Dev] The bytes type

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:

* Don't remove any feature for which an alternative doesn't already exist 
in 2.5

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

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