should i move on to python3

[Wensui Liu]

i started learning python with earlier version and am happy with it
and all related packages, such as scipy, pywin, and so on.
right now, i am wondering if i should move to python3. if i do, will
all packages working on earlier version still work in python3? this is
my major concern.
my another question is how many python users will move to python3.

any insight?
thanks a lot.

 

[Martin P. Hellwig]

i started learning python with earlier version and am happy with it
and all related packages, such as scipy, pywin, and so on.
right now, i am wondering if i should move to python3. if i do, will
all packages working on earlier version still work in python3? this is
my major concern. I wouldn't bet on it
my another question is how many python users will move to python3. Eventually all of them.

any insight?

Well I don't have insight in the mind of the core developers, but I
think you could compare it with any other major software upgrade.
Think of it like people upgrading from windows NT4 to 2000, some
software works some not, some people are happy with NT4 others prefer to
keep up with current technology. Look at it like py3 is 2000 before the
first service pack, internally it works, could need some polishing but
that's about it. The things that don't work are more often caused by
third parties then the core development.

thanks a lot.

If you want to be more on the safe side, I would say wait for 3.2 or
even 3.3 . More specific, wait till the external module developers (the
ones you use) say it is stable on Py3

 

[R. David Murray]

I wouldn't bet on it


Eventually all of them.


Well I don't have insight in the mind of the core developers, but I
think you could compare it with any other major software upgrade.
Think of it like people upgrading from windows NT4 to 2000, some
software works some not, some people are happy with NT4 others prefer to
keep up with current technology. Look at it like py3 is 2000 before the
first service pack, internally it works, could need some polishing but
that's about it. The things that don't work are more often caused by
third parties then the core development.

Comparing Python releases to Windows releases is...disturbing

If you want to be more on the safe side, I would say wait for 3.2 or
even 3.3 . More specific, wait till the external module developers (the
ones you use) say it is stable on Py3

As of 3.1 (which fixes the speed problems of the new io package),
I think the only reason not to move to python3 will be any
dependency one might have on 3rd party packages that haven't
themselves made the switch yet. Of course, that will be a big
issue for some time to come for many people.

 

[Martin P. Hellwig]

R. David Murray wrote:

Comparing Python releases to Windows releases is...disturbing

That was why I was very carefully in this example for choosing 2000

 

[Python Nutter]

Maybe if everyone shares their own thinking for their own situations
it may help.

I know the 2.x branch rather well, and cut my teeth on it.

My work involves x509 cryptographic materials and I cut my own
binaries and then wrap them in python to extend and enhance or build a
lot of automation around the binaries. I am the primary consumer of
the final programs so I don't wrap them in any sort of GUI. As such my
python touchpoints are rather slim on libraries. It took me all my
life up to a month ago to move off of os.popen and onto subprocess.
With this I could move between Python branches without much issue. I
do have an Ubuntu system at work as well as Windows so I'm a lazy sod
who didn't feel like building a custom Python build so I jus use what
comes with Ubuntu. Because of this I am stuck with a tenuous small
reliance on the 2.x branch, very small but add in lazy or not wanting
to use up xyz hours preparing new environments and learning a new
idioms and you might get the typical python user who encorporates it
at a job function where programming is not their job function but they
use python to help make the job eaier in a few areas.

I use more 3rd party modules at home and use the OS X platform
exclusively there. I wish I had time with the family but a lot of my
projects have been left by the wayside (web page scraping, games and
opengl programming, etc). Unlike Windows, tkinter GUI programs on OS X
could look native-ish. I always have aversions to making GUI programs
for distribution that require users install large dependencies so I
have shied away from doing them. With 3.1 it looks like themed tk
support is now added so that could be an incentive. That and I
silently troll python submitters and got the feeling 3.1 was what 3.0
was supposed to be ;-) so I been silently waking for 3.1 to go final
before spending time with the 3 branch to learn the changes.

In short if it's just you using your programs you have a lot of
flexibility in your choice of branch to use. If you distribute then
you are restricted by your end user branch sets even more. If you
heavily use 3rd party modules you are tied down further. So work
backwards and decide what is it you at writting, what features
internal and external are you using or desire to use and who will
consume your program. Then you'll have your answer or pretty close to
it.

Cheers,
PN

 

[Terry Reedy]

silently troll python submitters and got the feeling 3.1 was what 3.0
was supposed to be ;-)

I would say that it will be what the developers wish 3.0 had been. Part
of the problem was that not enough people downloaded and tested the 3.0
betas to discover certain problems before the release.

> so I been silently waking for 3.1 to go final
before spending time with the 3 branch to learn the changes.

You will, of course, then have to take what you get ;-). If you have
any unusual uses, please consider trying them out on a beta release.

tjr

 

[Mensanator]

I would say that it will be what the developers wish 3.0 had been. �Part
of the problem was that not enough people downloaded and tested the 3.0
betas to discover certain problems before the release.

That's the old chicken/egg question. People who depend on
third party libraries can't test beta versions of 3.0,
can they?

Nothing anybody can do anything about, just a comment.

 

[Tim Wintle]

Maybe if everyone shares their own thinking for their own situations
it may help.

Well, at work I do a mixture of things, some of which require python 2.3
(I know...), and some of which I can write to whatever version I want. I
generally use 2.5 for the second group. This is all work that runs live
all the time and has money running through it, so I'd rather not risk
moving to 3 for *any* of it until:

a) any security holes in python 3 have been fixed
b) it costs me more to stick with 2.x than to go through all of my code
line by line.

At home I normally write code for 2.5, as that's what comes with Ubuntu
Hardy (on my main, stable, machine), and most users will have 2.5 or 2.6
for quite a long time. For projects that are released, I'm planning to
stick to the advice Guido gave at Europython and keep working on 2.5/2.6
in trunk, but automatically generate a 3.x branch using 2to3.


I think it's going to be a bit like Java's JVMs (I can barely write
Java, but I use some Java projects) - I've got Java 5 and 6 running
different applications side by side here. In fact, I've got Sun's JVM
for 6 and 5, and IBM's JDK for Java 5 all running.

Similarly, on various machines I use CPython 2.3, 2.4, 2.5, 2.6 and
Jython 2.2 for various reasons - and I'm certainly planning on using
PyPy a large amount once it's stable.

I used the Beta of 3.0, but to be honest I haven't used it for anything
"proper" yet.

Tim Wintle