Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The real problem with Python 3 - no business case for conversion(was "I strongly dislike Python 3")

Reply
Thread Tools

The real problem with Python 3 - no business case for conversion(was "I strongly dislike Python 3")

 
 
John Nagle
Guest
Posts: n/a
 
      07-04-2010
On 7/4/2010 1:20 PM, sturlamolden wrote:
> On 2 Jul, 21:07, John Nagle<(E-Mail Removed)> wrote:
>
>> http://jens.mooseyard.com/2008/12/py...ats-the-point/

>
> He is right on. The only thing Python 3k will do for me, is break all
> my code and be incompatible with all extension modules I need. "What's
> the point?" indeed.


Exactly.

The "incompatible with all extension modules I need" part
is the problem right now. A good first step would be to
identify the top 5 or 10 modules that are blocking a move to
Python 3 by major projects with many users.

John Nagle

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-05-2010
On Sun, 04 Jul 2010 16:58:04 -0700, John Nagle wrote:

> The "incompatible with all extension modules I need" part
> is the problem right now. A good first step would be to identify the
> top 5 or 10 modules that are blocking a move to Python 3 by major
> projects with many users.


Are you volunteering to assist, or just belly-aching?

Migration to Python 3 is occurring at about the speed that should be
expected, modulo the setback that was the seriously flawed 3.0 release.
3.1 should be treated as the "early adopter" version. I would expect 3.3
will probably be the first "mainstream" version, where v3 users start to
outnumber v2 users.

If people have concrete, *specific* issues that are holding them back
from serious plans to migrate to Python 3 then reporting them is a good
first step: e.g. telling the author of extension module Foo that you need
Python 3 compatibility.

Complaining that "extension modules aren't compatible" is just bitching
for the sake of bitching and isn't helpful. Please take it elsewhere.
Start a blog "why I hate Python 3" or something. Or just stick with
Python 2.x forever, without the negativity. There's no law that says you
have to upgrade. There are people still using 1.5, and more power to them.



--
Steven
 
Reply With Quote
 
 
 
 
sturlamolden
Guest
Posts: n/a
 
      07-05-2010
On 5 Jul, 01:58, John Nagle <(E-Mail Removed)> wrote:

> * * *Exactly.
>
> * * *The "incompatible with all extension modules I need" part
> is the problem right now. *A good first step would be to
> identify the top 5 or 10 modules that are blocking a move to
> Python 3 by major projects with many users.


The big danger is Python 2.x becoming abandonware (2.7 being the final
release) before major projects are ported. Using Python 2.x for new
projects is not advisable (at least many will think so), and using 3.x
is not possible. What to do? It's not a helpful situation for Python.





 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      07-05-2010
On 7/4/2010 5:34 PM, sturlamolden wrote:
> On 5 Jul, 01:58, John Nagle<(E-Mail Removed)> wrote:
>
>> Exactly.
>>
>> The "incompatible with all extension modules I need" part is the
>> problem right now. A good first step would be to identify the top
>> 5 or 10 modules that are blocking a move to Python 3 by major
>> projects with many users.

>
> The big danger is Python 2.x becoming abandonware (2.7 being the
> final release) before major projects are ported. Using Python 2.x
> for new projects is not advisable (at least many will think so), and
> using 3.x is not possible. What to do? It's not a helpful situation
> for Python.


Projects have been known to get into a state where version N-1
is abandonware, and version N isn't usable yet. Then they die off.
The VRML-Web3D transition is an example. VRML 97 was ahead of its
time because few people had enough graphics power in 1997 to run it.
During the dot-com boom, the "Web 3D Consortium" (http://www.web3d.org)
was formed to put 3D on the web. The approach chosen was to recast
VRML in XML notation. Users were starting to get 3D boards in quantity,
and VRML was starting to really work. But the forced transition killed
work on VRML, while there wasn't enough momentum to get people to use
the XML version.

The Web3D consortium is still around. They have conferences.
They have something of a niche market in DoD training sims.
But they're running on empty. Nobody is paying attention. There's
no mainstream interest in either VRML or Web3D. It works fine;
there are X3D players, and they work great on modern graphics
processors. But nobody cares. That's what happens when you
mismanage an incompatible transition.

That could happen to Python.

Python has strong competition. In the last two years,
Javascript has become much faster, PHP is getting a JIT compiler,
Lua, as recently mentioned, is getting up there with C in speed, and
Google is promoting Go. The other scripting languages are becoming
rocket-powered. Meanwhile, Python is in year 2 of a 5-year plan to
transition to something that goes no faster (and maybe slower) than
the previous version. (Yes, there's Unladen Swallow and PyPy, but
neither of those projects seems to be anywhere near deployment,
and even if they succeed, their claimed speed goals are well below where
the competition is now.) That's just not good enough any more.

Denying that there's a problem does not help.

John Nagle
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-05-2010
On Jul 4, 8:59*pm, John Nagle <(E-Mail Removed)> wrote:

> That's what happens when you
> mismanage an incompatible transition.


+1

> * * Python has strong competition. *In the last two years,
> Javascript has become much faster, PHP is getting a JIT compiler,
> Lua, as recently mentioned, is getting up there with C in speed, and
> Google is promoting Go. *The other scripting languages are becoming
> rocket-powered. * Meanwhile, Python is in year 2 of a 5-year plan to
> transition to something that goes no faster (and maybe slower) than
> the previous version. *(Yes, there's Unladen Swallow and PyPy, but
> neither of those projects seems to be anywhere near deployment,
> and even if they succeed, their claimed speed goals are well below where
> the competition is now.) *That's just not good enough any more.
>
> * * Denying that there's a problem does not help.


+1

Hmm, i myself railed against the changes in Python3.x about 1 year
ago. Then, as i pondered the reasons behind such changes i began to
believe that the BDFL is wiser than us all! However, i must agree that
many of the points you bring up here are real. People ARE stuck in
limbo right now and there is no good direction to go... Stick with 2.x
and have all the 3rd party support but soon enough you will need to do
a major bug fixing, or move to 3.x -- oh wait i can't move to 3.x
because module xxyy is not 3.x compatible! What we have here gentlemen
is a situation, a terrible situation made worse by our lack to
understand it.

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      07-05-2010
On 7/4/2010 7:58 PM, John Nagle wrote:

> The "incompatible with all extension modules I need" part
> is the problem right now. A good first step would be to
> identify the top 5 or 10 modules that are blocking a move to
> Python 3 by major projects with many users.


Let me repeat. Last September, if not before, Guido identified numpy as
a top package blocking moves by other packages and projects. I am not
sure what he thought, but I consider it number 1. He encouraged the
numpy people to produce a 3.x version even though some did not see any
personal benefit. We supposedly will see numpy for 3.2. If we actually
do, other dominoes will fall into place.

I you have any other ideas about other top blockers, please share them.

--
Terry Jan Reedy

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-05-2010
On Sun, 04 Jul 2010 17:34:04 -0700, sturlamolden wrote:

> Using Python 2.x for new
> projects is not advisable (at least many will think so), and using 3.x
> is not possible. What to do? It's not a helpful situation for Python.


That's pure FUD.

Python 2.7 will be supported longer than the normal support period for
versions 2.6, 2.5, 2.4, ... so if you have a new project that requires
libraries that aren't available for 3.1, then go right ahead and use 2.7.
By the time 2.7 is no longer supported (probably around the time 3.4
comes out?), the library situation will be fixed.

Those 3.1 features that can be backported to 2.x have been, specifically
to reduce the pain in porting 2.7-based applications to 3.x. Feature-
wise, 2.7 is designed to ease the transition from the 2.x series to the
3.x series. Claiming that it's not advisable to use 2.7 is simply
nonsense.



--
Steven
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      07-05-2010
On 7/4/2010 10:44 PM, Terry Reedy wrote:
> On 7/4/2010 7:58 PM, John Nagle wrote:
>
>> The "incompatible with all extension modules I need" part
>> is the problem right now. A good first step would be to
>> identify the top 5 or 10 modules that are blocking a move to
>> Python 3 by major projects with many users.

>
> Let me repeat. Last September, if not before, Guido identified numpy as
> a top package blocking moves by other packages and projects. I am not
> sure what he thought, but I consider it number 1. He encouraged the
> numpy people to produce a 3.x version even though some did not see any
> personal benefit. We supposedly will see numpy for 3.2. If we actually
> do, other dominoes will fall into place.
>
> I you have any other ideas about other top blockers, please share them.


The Twisted team has a list of what they need:

"http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3"

* Zope Interface
* PyCrypto
* PyOpenSSL
* PyGTK


John Nagle

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-05-2010
On Sun, 04 Jul 2010 18:59:03 -0700, John Nagle wrote:

> Denying that there's a problem does not help.


Nobody is denying that there is a problem, but there are plenty of people
denying that there are any solutions.

The folks doing development of CPython are genuinely interested in
constructive criticism. Go spend some time on the python-dev mailing list
to see that they're serious about resolving problems. But harping on and
on with the same old negatives and same old FUD ("Python is too slow,
nothing works with Python 3, people will abandon Python, the transition
is being mismanaged, blah blah blah blah") conspicuously lacking in
*actual* details is not helping anyone.

Let's hear specifics. What is your project, what is the project timeline,
why did you want to use 3.1 (instead of, say, waiting for 3.2) and what
*specific* problem stopped you? I'm not interested in hand-waving and
vague generalities. I want to hear names and versions, not bitching.

"We are planning on building an app to do Foo, and choose to target 2.6
instead of 3.1 because the 3rd party FooLib only supports 2.5 and 2.6..."

"I wrote an app using 3.1, and ran into these really painful problems
with this library..."

That's the sort of thing that is helpful.

By the same token, if you've successfully targeted 3.1, we'd love to hear
your success stories too.



--
Steven
 
Reply With Quote
 
David Cournapeau
Guest
Posts: n/a
 
      07-05-2010
On Mon, Jul 5, 2010 at 12:44 PM, Terry Reedy <(E-Mail Removed)> wrote:
> On 7/4/2010 7:58 PM, John Nagle wrote:
>
>> The "incompatible with all extension modules I need" part
>> is the problem right now. A good first step would be to
>> identify the top 5 or 10 modules that are blocking a move to
>> Python 3 by major projects with many users.

>
> Let me repeat. Last September, if not before, Guido identified numpy as a
> top package blocking moves by other packages and projects. I am not sure
> what he thought, but I consider it number 1. He encouraged the numpy people
> to produce a 3.x version even though some did not see any personal benefit.
> We supposedly will see numpy for 3.2.


I think numpy will work for 3.1 as well (I don't know about 3.0, but
my understanding is that there is no point into even looking at that
release).

With the scipy conferences going on, it will certainly be a good
occasion to synchronize a bit faster - nothing beats face to face as a
communication medium after all

David
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: I strongly dislike Python 3 Thomas Jollans Python 52 07-01-2010 11:07 PM
Re: I strongly dislike Python 3 Terry Reedy Python 43 07-01-2010 02:26 AM
Re: I strongly dislike Python 3 Stefan Reich Python 5 06-27-2010 05:39 PM
Re: I strongly dislike Python 3 Stephen Hansen Python 12 06-27-2010 05:21 PM
I strongly dislike Python 3 Stefan Reich Python 1 06-27-2010 06:59 AM



Advertisments