At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
>On 1/16/07, James Y Knight <[EMAIL PROTECTED]> 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
