[makmanalp]

I see many comments talking about how this will slow down the migration process. But I don't think the situation is that bad.

Most of the py3 wall of superpowers is now green (https://python3wos.appspot.com/) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already.

So one interesting effect of this is that now that there is some critical mass and people are starting new projects in python3, there is now pressure on package maintainers to have py3 ports. So it's users dragging the packages forward now rather than the packages dragging the users backwards.

[kmike84]

Just a quick note: NLTK supports Python 3 for more than year in the main github branch; there were several alpha releases that support Python 3, but no "stable" pypi release or a beta. There is no stable release because of unfinished tasks unrelated to Python 3 support.

[lucian1900]

Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc.

The list is still too long.

[chomp]

Have no fear, Paramiko supports Python 3 as of 1 month ago:

https://pypi.python.org/pypi/paramiko/1.13.0

Fabric won't be far behind after this.

[makmanalp]

IMHO there are great py3 alternatives for all of those. Which won't help you when porting, but it won't stop new applications from starting in py3 and will move the process further.

[kmike84]

Alternatives don't help when some other project depend on a package that is not fully ported. And this is a problem. It is still a bit harder to quickly build something using Python 3.x. Check trending Python repos for this month:

* portia doesn't work in 3.x because of scrapy, twisted and scrapely;

* psdash - developers don't care;

* jasper-client - developers don't care;

* ansible - Paramico was not ported when development started, now it is a big task to port ansible;

* scrapy - depends on twisted;

* heartbleed-masstest - developers don't care;

* planout - developers don't care;

* beets - not sure what's the reason, either some dependencies or developers don't care;

* reddit - no reason to move for 3.x for a large codebase which is not a library;

* salt - docs says it needs Python < 3 (maybe the reason is similar to ansible's);

* pacemaker - developers don't care;

* pyjvm - developers don't care;

* sentry - large codebase which is not a library.

That's not bad (12 trending packages have 3.x support, 13 don't). But clearly something stops some new packages from starting in py3, and many packages that people find interesting don't work in 3.x. I think that the only way to improve this is to help porting "base" packages that ecosystems depend on; just providing alternatives is usually not a good answer.

[benselme]

* psdash developers don't care ? then why is this: https://github.com/Jahaja/psdash/commit/f05c8e0a1011603d5ef4... * Twisted is getting ported. Scrapy too, according to the FAQ. * Beets ? http://beets.radbox.org/blog/py3k.html * PyJVM ? Who cares ? My point being, the whole community is moving forward.

[kmike84]

Cool about psdash, the commit didn't exist when I started to write the comment :)

Twisted and Scrapy are getting ported, and the community is moving forward. But this is not happening because of a miracle - people are making it happen. My point was not that Python 3.x is bad (I think it is good), it was that community still needs help, that writing alternative software is not the best way to do it, and that there are still reasons why writing new Python 2.x code is easier.

Praising 3.x won't make users switch if they need some unported package, and bashing 3.x won't make other people's lives easier either. So let's help twisted, scrapy and other modules to become 3.x compatible.

Scrapy reached an important milestone recently - its test runner can now run tests under Python 3.x; test runner was the main reason why porting haven't really started before. If anybody wants to help then ping me kmike84 at gmail.com, or check https://github.com/scrapy/scrapy/pull/682, or go to ScrapingHub booth at PyCon and talk to people there.

[yeukhon]

The reason is probably because most people are still more confident writing in Python 2 and many users are using Python 2. Though many of the simple programs really don't require advance features which are only available in python 3. In other words, many of the new projects can be Python 2 and 3 compatible without effort.

[bitL]

boto.mws is absolutely essential for e-commerce on Amazon. I can't even think of moving to 3.x because of that. Not to mention other critical components like Excel processing etc. 2->3 is a major problem in Python, can't understand the thinking behind breaking that much compatibility. Compare this to Java.

[rspeer]

NLTK's situation isn't as bad as it looks. I use NLTK 3.0a, which does support Python 3, all the time.

I suppose they're not officially releasing it because there may be some unloved corners of the library that don't work yet on Python 3. But everything I've done with it has worked fine.

[kmike84]

That's great that you use NLTK3 and Python 3.x and it works fine! There are no known Python 3.x incompatibilities. But if you find something then please report it.

Issues that prevent a release are not related to Python 3: check https://github.com/nltk/nltk/issues?milestone=2&state=open, https://github.com/nltk/nltk/issues?milestone=3&state=open and https://github.com/nltk/nltk/issues?milestone=1&state=open.

[antocv]

Many reds on the list also have py3 support in branches or forks for unmaintained ones like suds.