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

J

John Nagle

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.
Click to expand...

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
 
S

Steven D'Aprano

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.
Click to expand...

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.
 
S

sturlamolden

     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.
Click to expand...

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.
 
J

John Nagle

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.
Click to expand...

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
 
R

rantingrick

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.
Click to expand...

+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.
 
T

Terry Reedy

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.
Click to expand...

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.
 
S

Steven D'Aprano

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.
Click to expand...

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.
 
J

John Nagle

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.
Click to expand...

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
 
S

Steven D'Aprano

Denying that there's a problem does not help.
Click to expand...

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.
 
D

David Cournapeau

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.
Click to expand...

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
 
T

Terry Reedy

I think numpy will work for 3.1 as well
Click to expand...

If numpy were released today for 3.1 (or even anytime before 3.2), that
would be great. It would let those waiting for it that it is real and
that they can go ahead on their ports.

Part of the reason for the 3.2 core-change moratorium was to let
3rd-party packages target 3.2 by working with 3.1. If they finish and
release sooner (as some have), even better. Unless they depend on
something that changes in the stdlib, porting for one should pretty much
be porting for both.
(I don't know about 3.0, but
my understanding is that there is no point into even looking at that
release).
Click to expand...

Agreed.
 
D

D'Arcy J.M. Cain

Good start. Now what is blocking those four?
Lack of developer interest/time/ability?
or something else that they need?
Click to expand...

How about a basic how-to document? I maintain PyGreSQL and would like
to move it to 3.x right now but I don't even know what the issues are.
I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but that
hits the time issue above. If there was a relatively simple document
that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level? That would make things easy.
 
M

Martin v. Loewis

Am 05.07.2010 22:30, schrieb D'Arcy J.M. Cain:
How about a basic how-to document? I maintain PyGreSQL and would like
to move it to 3.x right now but I don't even know what the issues are.
I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but that
hits the time issue above. If there was a relatively simple document
that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level? That would make things easy.
Click to expand...

If somebody would move that into a narrative form, I'd be happy to
list the changes I know of, and the approaches I took to make C modules
work on both 2.x and 3.x (actually, I did the port of psycopg2, so I
expect PyGreSQL might be similar).

However, I'm not willing to maintain such a document - I have too many
projects already, and English is not my native language.

Regards,
Martin
 
P

Philip Semanchuk

How about a basic how-to document? I maintain PyGreSQL and would like
to move it to 3.x right now but I don't even know what the issues are.
I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but that
hits the time issue above. If there was a relatively simple document
that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level? That would make things easy.
Click to expand...

There are definitely changes at the C level.

I ported two pure C extensions from 2 to 3 and was even able to keep a
single C codebase. I'd be willing to contribute my experiences to a
document somewhere. (Is there a Wiki?) I would have found such a
document very helpful before I started porting.

Cheers
Philip
 
T

Terry Reedy

Thanks. I don't want to appear ungrateful, but I was hoping for
something specific to the 2-to-3 conversion. I guess someone has to
start somewhere...
Click to expand...

There is an existing 2to3 and other pages for Python code conversion. I
do not know of any for CAPI conversion. The need for such has been
acknowledged among the devs but if there is nothing yet, we need someone
with specialized experience and a bit of time to make a first draft. If
you start one, give it an easy to remember name C2to3? 2to3Capi? You
choose. And link to it from the 2to3 page

In his post on this thread, Martin Loewis volunteered to list what he
knows from psycopg2 if someone else will edit.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

I strongly dislike Python 3 1
Python 2-3 compatibility 0
Did you know that there is a match-case function in python? 4
Will Python 3.x ever become the actual standard? 37
API design for Python 2 / 3 compatibility 3
python 3's adoption 71
Performance of int/long in Python 3 187
An ODBC interface for Python 3? 1

Members online

No members online now.
Total: 35 (members: 0, guests: 35)
Robots: 452

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top