barry at python
Nov 3, 2009, 5:09 AM
Post #20 of 131
(1380 views)
Permalink
|
|
Re: 2.7 Release? 2.7 == last of the 2.x line?
[In reply to]
|
|
On Nov 2, 2009, at 11:51 PM, ssteinerX [at] gmail wrote:
> I agree as long as:
> A> 2.7 comes out as soon as possible, even if it's missing helpful
> porting features.
> B> 2.7 will get ONLY new features that make it easier to port to
> 3.x, not every feature added to 3.x or all you've done is make
> "Python 2.7, the Python 3 Version." and core developer time will
> continue to be wasted on Python 2.7 instead of moving forward.
I'm not sure I agree with that core developer time will be "wasted on
Python 2.7 instead of moving forward". However, I completely
understand core developers seeing Python 2.x as a dead end and not
wanting to work on it. If that's a real issue, we should acknowledge
that as a factor in the decision. This is a volunteer organization
and if the majority of developers are sick and tired of Python 2, then
it absolutely makes no sense to slog through a Python 2.7 release.
I'd much rather take all the enthusiastic energy that decision will
reclaim and focus it on, oh, Python 3's email package instead <wink>.
>> I also think Guido's call for feature freeze makes a lot more sense
>> when 2.7 is the EOL. Let's give people migrating to Python 3 a
>> nice big stable target to hit. Improving the stdlib also gives
>> people a big carrot to move.
>
> Agreed. And specifically NOT porting every shiny new toy from Python
> 3 back to 2.7 makes sure the carrots are only in the 3.x series.
Python 3's got enough carrots and sticks already. One huge carrot
that will never make it back into Python 2 is bytes/strings of
course. The huge stick is that Python 2 is end-of-lifed, if not now,
eventually. It isn't going to get a reprieve. Everyone knows that
everyone will have to get to Python 3. The question is, what can we
as a community do to make that inevitability as easy to swallow as
possible?
>> I think it's also necessary to give third party library and
>> application authors as much help as possible to provide Python 3
>> compatible software. Putting together Python tools involves so
>> many dependencies in a fairly deep stack that even one unconverted
>> library can cause everything above it to stall on Python 2.
>
> And that's one of the reasons my explorations into Python 3 have
> been limited to pretty much nothing.
>
> I don't have time to do a bunch of work only to find out that the
> tool I absolutely have to have to finish a project doesn't have a
> Python 3 version or has been crippled to make a Python 3 version.
Unfortunately, I think we have to do those explorations, fail, hit
roadblocks, complain, etc. but most importantly identify the packages
that need to be ported. Then work with those package authors to make
the upgrades happen. And improve Python and Pythonic tools so that
migrations can go smoothly.
Speaking as a package author, I know how much work it is just to get a
bug fix release out. The three lines of code fix means 50 lines of
test writing, a half a day of documenting, packaging, uploading, and
announcing. Porting even one of my packages to Python 3 is a
significant undertaking which frankly I don't have the cycles for.
Anything large and complicated is hopeless. Witness how long and
difficult it's been just to get a standard library module updated
(email) and you get a sense of how much work it will be to get an
entire stack of code onto Python 3.
> BeautifulSoup, which I use every day, is one such product. Since
> the crappy old SMGL parser's gone, BeautifulSoup uses the one that's
> left in Python 3 and it makes BeautifulSoup completely useless for
> my daily work.
>
> That's not to say I can't fix that one particular project, but
> customers get cranky when their project is taking longer than
> expected and "Oh, I'm having to convert a lot of things to use
> Python 3" doesn't seem to improve their mood much.
I completely agree. What happens when your application depends on a
half dozen Zope packages, Twisted, and 15 or 20 other established,
mature packages? It's a daunting prospect.
-Barry
|
PGP.sig
1
