tags:

views:

317

answers:

5

What Python version can you please recommend for a long-term (years) project? Should one use 2.6+ or 3.x is already stable? (only standard libraries are required)

UPDATE: according to the answers below, Python 3.x still has critical bugs. Please also see Python's list of bugs.

A: 

If you are starting your project now, and all the third party libraries you want to use are already ported to Python 3, and your target operating system (I really mean linux distribution) packages Python 3, then sure.

Go ahead, use Python 3.

ddaa
+4  A: 

There's nothing wrong with Python 3, but many libraries haven't been ported yet. For example, from PyGame FAQ:

Python 3 support is incomplete and still in the development stage

And from NumPy:

Support for Python 3 is planned, but not yet scheduled.

It all depends on how important 3rd party libraries are to you, and whether they're ported yet.

Skilldrick
@Skilldrick, the Python 3.0 release did have something wrong, if I recall, which was abysmal performance in file I/O. If that was true, has it been fully fixed in 3.1, or are there still some fairly significant performance problems relative to Python 2.x?
Peter Hansen
According to this it has: http://bugs.python.org/issue4565
Skilldrick
http://docs.python.org/3.1/whatsnew/3.1.html#optimizations
Ned Deily
+1  A: 

I think it boils down to how closely you can control the environment in which your application will run. If you are producing a piece of software in which your customer will 'install' python to run your software, then you might as well use the latest release (Python 3.x). If you are targeting existing python installs then choosing 2.5 or 2.6 compatibility would be best since those are more widespread.

Python 3.x is stable. That is not the issue. The issue with it is compatibility. If you have the ability to use the latest and greatest then you should use the new version. For new projects, 3.x would be the obvious choice.

Chris Dail
Do you know, will Python 3.x support true multithreading?
psihodelia
@psihodelia, if you mean, without the GIL that prevents CPython from fully taking advantage of multicore processors without resorting to the multiprocessing package, the answer is no, Python 3 will not fix that issue AFAIK.
Peter Hansen
It means, that even if in N-years we will have multiple CPUs, only one thread may be doing things at a time. Right? So bad...
psihodelia
Do not forget the multiprocessing package. http://docs.python.org/3.1/library/multiprocessing.html
codeape
+3  A: 

The good thing about Python3 is that there is a automatic way to port your programs from Python2. But the program has to meet certain criteria.

I think the best approach for now is to write Python2 code and test it in Python3 test mode (run python -3 program.py). This way you don't have to worry about missing libraries now and you can convert your program to Python3 as soon as that makes sense.

THC4k
+1  A: 

THC4k mentions 2to3, and I just wanted to point out that there's also a 3to2 package. I've never used either package, but I've heard that 3to2 is more forgiving than 2to3.

Edit: just wanted to emphasize what others have suggested: If you choose to use one of these converters to release your software for either 2.6 or 3.0, you'll probably want to have a solid testing system in place (unittest, doctest, etc) with decent test coverage to sleep soundly at night!

Pete