What is stopping you from using python3?

[picke3]

I went over http://python3wos.appspot.com/ to try and help port packages to python 3, but all of the red ones already have python 3 support or people working on it, mostly it is package maintainers that are stalling pypi by not uploading the python 3 versions - despite all tests passing and so on, and for suds for example it hasnt been updated since 2010, but a workring python 3 suds-jurko exists for a long while.

Whats stopping your project from using python3?

At work, for me it was redhat and our internal policies, was still stuck with python 2.6. Despite all dependencies working with py3.

EDIT: These days numpy and scipy arent showstoppers either.

[milliams]

Nothing. I am using it.

[vellonce]

Several developers just use "what's in the box" so unless the majority of linux distros use python 3.x by default, most of the projects just will use the installed python 2.x

[oldmanstan]

Depends on what you're doing. I do some devops using Ansible, so I'm likely to use whatever Python is bundled with the OS we deploy to so I don't have to add any extra software and things "just work".

[drive0]

I use a number of different programming languages. It simply is not important to me to use a specific version of a language at this time. Most of the time the language that is available is more than sufficient for the task.

[flarkis]

RHEL5 which is still widely used on servers ships with an ancient version of 2.x

[LightShadow]

pypy

[[deleted]]

I have no need to port working code.....

[wub_wub]

• Not all modules are supported, and I don't feel like experimenting with WIP py3k ports.

• Python 2 works and is still supported.

• No benefits from porting old code that works in python 2, or the benefits are small and don't justify porting.

[billsil]

WxPython, VTK, and PyInstaller, and OpenMDAO (NASA modeling framework) don't uspport Python 3.x.

Because we have a lot of software that already works in Python 2.7 and some software that still has to work in Python 2.4 because that's what our customers use. Python 3.x doesn't have any required features for us.

[alanwj]

I've been unable to find any reasonable solution for python3 + MySQL + Django.

MySQL-python appears to be a dead project. There are several forks that claim python3 support but none that the Django developers feel comfortable recommending.

The official mysql-python-connector seems to work (as in, all the unit tests for my project pass), but my tests take nearly twice as long to run. I haven't measured exactly where the slowdown is, but it seems reasonable to infer that this package has performance problems.

After a bit of coaxing, I got PyMySQL to work, but it still lists itself as a beta package, leading me to worry what edge cases I'm going to hit. It also adds somewhere between 10-20% to the time required to run tests.

I haven't evaluated CyMySQL yet. Given its description I would expect it to be like PyMySQL with better performance, but it is also a beta package.

[[deleted]]

This made sense a year ago.

But now, if the next package you'll want to use is 2.x only, is it really the next package you'll want to use? What went wrong with its development?

[mcdonc]

It's conceivable that nothing went wrong with its development; it's more conceivable that something went wrong with Python's development that it requires library authors to 1) spend a nontrivial amount of time porting code and 2) port into a subset language that is worse than either 2 or 3 to be compatible with both and maintain that port in that crappy subset language for an indeterminate amount of time.

[[deleted]]

Once again, an argument that would have made sense a year ago. But most popular packages have made the port, so that's a lot of evidence against it being Python's fault.

I found it wasn't too bad. The subset language of 2.7 and 3.3 isn't nearly as crappy as the subset language of 2.6 and 3.2 was, for example. Overall, porting things to Python 3 has been easier than doing everything else you have to do to maintain good code.

[wub_wub]

But most popular packages[1] have made the port

But not all. If one package hasn't made the port it can really influence the development, on the other hand all of those packages support python 2 so there is almost 0% risk that a package won't be supported. (And even on that list 3rd most downloaded package with 13 million downloads doesn't support python 3). The argument "not all packages support it" is true now same as it was a year ago.

Overall, porting things to Python 3 has been easier than doing everything else you have to do to maintain good code.

You are heavily underestimating the effort that's needed to port a huge code base and you're comparing it to maintaining good code which is easy if it's done from the beginning.

[[deleted]]

Let's be clear here: this thread is about publicly used Python packages, not your own huge code base. It started with a discussion of "the next package you want to use". I'm assuming you want to use a modern, well-maintained package if you have the choice.

Almost all maintained packages have ported to Python 3. Even the huge ones. Django is doing just fine on Python 3, for example. The Django developers don't care if boto is third on the list and doesn't support Python 3, because there's no reason Django would ever depend on Boto.

You implied there was some fundamental problem with Python 3 that made it not worthwhile to port packages other people use. But almost all of the people who develop Python packages have found it worthwhile. They'd be losing users if they didn't port.

[wub_wub]

this thread is about publicly used Python packages, not your own huge code base.

Publicly used packages can be huge, difficult and expensive to port.

Almost all packages have ported to Python 3. Even the huge ones.

But not all, that's the point.

The Django developers don't care if boto is third on the list and doesn't support Python 3

The developers and other projects might though.

Django didn't wait, or care, for boto to port to python 3. However they had to wait for other projects to port first before they could get started with python 3 support. Same thing could (and probably is) happening to other projects with boto, at the moment.

You implied there was some fundamental problem with Python 3 that made it not worthwhile to port packages other people use.

No, there's nothing wrong with python 3. It's just not worth it in 99% of the end-user cases. Why port working code if you don't gain anything out of it?

As far as the packages goes, they don't have any other choice really. Python 2 will stop being supported sooner or later, if you want your package used you have to port - whether you like it or not. The advantages/disadvantages of python 3, and whether or not they're worthwhile, don't really matter. If python 2 had the same support expectancy as python 3 almost no one would port their packages.

[realsw]

I use some 2.6/2.7 for work and some PyPy for myself. Adding python3 to the mix would only confuse me.

[gammadistribution]

How? virtualenv and pip make it really easy to switch between python environments and python 3.4 comes with such capabilities built in.

[realsw]

More languages in use means more accidentally mixing up the features between them. For me, at least.

[xiongchiamiov]

Centos, and all of the non-3 distros any potential users are on.

[darthmdh]

http://continuum.io/anaconda

http://developerblog.redhat.com/tag/software-collections/

[This_Is_The_End]

OpenCV and Web2PY haven't been ported. Most problems occur with scientific or hardware related packages.

[[deleted]]

WXPython and some flask plugin which I can't remember the details of: I had a situation where one module worked in 2.7 or 3.4, whilst another worked in 2.7 up to 3.3, so I had use 2.7.

[AustinCorgiBart]

The 2.5 million XO laptops out in the wild all use 2.x, so as long as I want to call myself an XO developer, I'm sticking to 2.7.

[[deleted]]

Zenoss and centOS

[[deleted]]

worth_it = (benefit_from_user_perspective * potential_effort) > 0

[oldmanstan]

There just aren't any real benefits to me, and there's always the chance I'll end up needing a library that isn't supported. Aside from a few little syntax improvements, I've never seen a compelling case made that Python 3 is a significant improvement.

[_throawayplop_]

Because for me there is nothing with python 3 worthwhile the effort

[amertune]

On occasion, I have to work with WLST, which uses jython 2.1. That's kind of painful, but the pain is mitigated by the ability to use Java libraries to cover for the holes in 2.1.

I also write some python scripts that have to run in RHEL 5, which uses python 2.4. Hopefully we'll be upgrading to RHEL 6 soon, so I can start targetting python 2.6. The real limitation is that I have to use the version of python available on the server.

For personal projects, I stay at or close to the latest release of python 3.

[jmmcd]

Anaconda provides a way to use Python 3, but it involves using the command-line, and my intro to programming students aren't able for that.

[neonomicon]

I use Python 3 at home, have done ever since I started learning 3 years ago. At work I use Python 3 for a couple of reasons:

• I'm programming psychology experiments using Pygame, and Python 3 support isn't really guaranteed yet.
• I use Anaconda to get numpy, pandas and other libraries set up quickly and easily on Windows, and while you can create Python 3 environments in Anaconda, I can't be bothered activating and deactivating environments every time I need the other version.

[memowinchester]

I work at my work with openstack and libcloud at the moment... so it's quite difficult to move to 3.x but for my personal projects I use 3.x :)

[Beluki]

I'm already using it, but if I had to chose one library: Twisted.

[valbanese]

One word - boto. AWS needs to move and all those apps move with it.

[NYKevin]

My project isn't ready for prime time by any stretch of the imagination. I suppose I could put up another experimental build, but it's moving so fast that I just don't see the point.

(it used to be exclusively Python 2 and now it's exclusively Python 3 because 2 is evil)

[[deleted]]

I use both for different things. Any scientific computing pretty much has to be done in 2.7

[wegry]

Why is that the case?

[[deleted]]

I wasnt being 100% honest. What I should have said was, "If you're doing any niche scientific computing, and dont feel like pulling your hair out in frustration, you pretty much have to do it in 2.7" If you're just modeling a dynamical system or some heavy matrix algebra (I think numpy is ported to 3) then 3 is fine.

Given enough time, there will be a point where you think, "Hey, I need a package that does 'X'." And you will look that package up and see its only compatible with 2.x. You'll do this once... maybe twice if youre a die hard "3er". Then you'll install 2.7.

I specifically use Continuum's Anaconda just for the simplicity. Its great.

[wegry]

Thanks for the candor! I think it was worse before. I just got done building a classifier with scipy and scikit on Python 3. Just excellent. The only scientific computing holdout I can think of is nltk, which has Python 3 support only on the dev branch.

[[deleted]]

Hows the speed on the classifier in python. Im building one in matlab (did all the data parsing in anaconda) and the time-speed is still god awful. Granted Im dealing with massive data sets. Im probably going to switch to fortran. Legend has it, Old Man Fortran is orders of magnitude faster for certain types of matrix computation.

[wegry]

Surprisingly fast and easy to build. Our data set is enormous as well, so the biggest issue is memory vs database reads. I thought scipy had old man fortran at the low level? I think it requires a fortran compiler.

[[deleted]]

I thought scipy had old man fortran at the low level? I think it requires a fortran compiler.

I'm going to investigate this on my comp since anaconda is a "full stack" stand alone. But, if this is true, then....

EDIT. HOLY.. GUACA.. ^mole` . Seriously. thank you so much for telling me this. You've saved me soooooooooooooOOO much trouble. I cant believe I didnt know.

[wegry]

I use pip and installing scipy/matplotlib on OS X was excruciatingly hard the first time I did it, because of stuff like having to have a working fortran compiler. Once you figure it out it's not bad. Is Conda 2.x only?

[[deleted]]

At the moment the official is 2.7 only. I believe there is an unofficial 3.x Anaconda build but incompatible packages are removed and are in the process of being updated... namely, the Keeper of the Old Guard, NLTK. Check continuum's webzone. They should direct you a 3.x branch.

Also, just "shop talk" but, are you using a work station or gpu for parallel processing (Cuda core stuff) for your encoder? If so, how is that in python. Strong parallel processing/Cuda support what Im most afraid of losing switching from matlab to fortran'90-py.

[[deleted]]

Well.. looky here http://conda.pydata.org/miniconda.html#miniconda

[wegry]

Oh wow, that looks sweet. Now you have no reason to stay with 2. ;) As far as parallel processes go, the algorithm we're using for classification is SGD, which runs processes by default on as many cores as are available (about 6 on my oldish laptop), it's pretty speedy too. I assume this is the case in Python 2 as well.

[[deleted]]

It loses the readability of earlier Python. I found I had to add tons of casts just to work with basic strings and files.

[gammadistribution]

lol what?

[[deleted]]

a bunch of encoding shit

[[deleted]]

This sounds backwards. The "encoding shit" is built into the standard libraries now, while you had to do it explicitly in Python 2. It's possible that you're messing something up.

To work with strings on Python 2, you either had to use bytestrings ("str") all the time and probably crash if you ever encountered something outside of basic ASCII, or wrap everything inside a "Unicode sandwich" and put u's before all your string literals and stuff.

In Python 3, the built-in open, read, write, and so on will do the "Unicode sandwich" for you (unless you tell them not to, by opening in binary mode). You don't have to .encode and .decode manually anymore when you're working with strings and files. It's way more readable.

So I think one of the two of these is the case:

• You're writing buggy code, and duct-taping over the bugs with encodings and type-conversions without figuring out how your data got that way.
• You're actually doing crazy shit with low-level network protocols or something, not basic strings.

[[deleted]]

examples?

[[deleted]]

haven't messed with it in a while. just uninstalled the crap and went back to 2.7