[Python-Dev] The bytes type
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
> 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
> 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."""
> 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