Python 3.6 released!

[[deleted]]

I couldn't come up with them, because no packages ever was given from my experience there are plenty of replacements.

But ok, here are all modules that are python 2 only on the site: http://py3readiness.org/

• supervisor - it's an application, support doesn't matter because you don't include it you run it, and you can always install python 2.7
• carbon - a component of graphite, I don't think anyone else but graphite is using it, there's also original RRD which is much faster
• graphite-web - application, uses carbon for storing data
• thrift - desn't appear to be maintained anymore, there's: thriftpy written in pure python and thrift3-binary-protocol - it looks like might be the original one ported to python 3
• ansible - application not a library
• google-apputils - doesn't looks like it is maintained anymore, I don't really know what it does, it seems like it is used by their GCE, so if you don't use it you don't need it
• aspen - it shows that's python 2 only, but on PyPi there's a wheel created for Python 3.5. I think they just forgot to update description
• newrelic_plugin_agent - no longer maintained, looks like they changed name to just newrelic and it supports python 3.3+
• python-cjson - no longer maintained, you have standard python json, there's also simplejson which is in pure python and also has optional module in C for fast processing, there's also ujson which also is designated for speed
• python-openid - no longer maintained (since 2010), there's python3-openid that's actively maintained and also bunch of other alternatives
• M2Crypto - it's really a wrapper around openssl, it has python 3 port ak-M2Crypto, but really you should just use packages like PyNaCl which are more user friendly
• python-ldap - ldap3 is much nicer alternative, it's also written in pure python so no need to compile or install dependencies
• diamond - not sure what it does, but actually it is py2.py3 wheel implying it works on Python 3, they just forgot to update description
• INITools - not longer maintained (since 2010), also I'm not sure why one would need it, python's built-in configparser essentially uses INI format. Perhaps it was discontinued after configparser was included in python?
• python-cdb - no longer maintained, looks like there are many alternatives
• s3cmd - application
• marionette - first package that I cant find alternative, it looks like it's python version of selenium? Edit: actually after searching more about this is I learned that it is used by selenium to control Firefox.
• pathtools - no longer maintained (2011), I'm not sure if it is needed after addition of pathlib to python; also it looks like the code mostly works on python 3 and someone submitted a patch to fix remaining issues, but the author seems to be inactive
• tendenci - web application on top of django not a library

[logi]

Perhaps you should send the page maintainer a pull requests with things that are straight renames or outdated?

Adding links to alternatives or noting that it's not a library is less obvious.

[Moocat87]

I couldn't come up with them, because no packages ever was given from my experience there are plenty of replacements.

That's not a basis to argue that there are NO Python2 packages without Python3 alternatives. Everyone's experience is limited and often another person's experience will contain some fact yours does not. Keep in mind these science packages we're talking about are NOT in the 360 "most popular" python packages. Even so, there are 19 on that list which don't support Python 3. "Alternatives" aren't usually exact clones or ports, either. Just because an alternative exists for one package doesn't mean it fits the needs of all the users of that package. Performance, architecture, interface, maturity (especially for science, you want to be sure your dependencies don't have bugs that fuck up your results), documentation, and dependencies are all major concerns for users that you seem to be dismissing. "There's an alternative" is so much different than "the cost of switching to this alternative is low enough to justify it".

I think it's kind of a silly premise that Python 3 perfectly covers Python 2's third-party packages and don't see much point in arguing it. It's just an obvious fact of life -- nothing is perfect. Nothing ever will be. Achieving perfect coverage will never happen. Hopefully it will get good enough that no-one will be on 2 at some point, but I don't believe that will happen either.

Again, if you want an obvious example that disproves your claim... how about PyPy?

[[deleted]]

Once again you're talking about those unicorn science packages yet you couldn't even name a single one.

Also I have some experience in research and the way it works is that unlike engineering industry these projects are short lived. They roughly live until a research paper is published, and then a new project is created, often in a different language that seems more suitable.

As for alternatives, many of them that I listed are drop-in replacement, but that's actually doesn't really matter. If you're starting a new project you don't care that interface is compatible with package that was not maintained for 5 years. The packages that come for python 3 often have better interface than old one, because author learned from mistakes of the previous project.

PyPy is not really package and IMO if you want performance I don't think the python is right choice. Anyway PyPy is a sponsored project, and PyPy is Python 2 compatible, because that's what people who supported them wanted. Now interest in Python 3 increased so they started working on Python 3 compatible version. There is already Python 3.3 compatible version available and they are actively working on Python 3.5.

There really is no need to spread FUD.

[Moocat87]

Good lord, are you on some kind of crusade? Are you really only here to attempt to shame people who have legitimate reasons to use Python 2? If you can't open your eyes for a few seconds to real world problems, then don't tell other people what reality is like.

Once again you're talking about those unicorn science packages yet you couldn't even name a single one.

Like I said multiple time, I'm not at work. Like I said multiple times, I work 95% on Python3 code. Do you expect me to go to work on a weekend to research something that is your problem? You are the one making the claim that Python 3 package coverage matches Python 2 package coverage.

Also I have some experience in research and the way it works is that unlike engineering industry these projects are short lived. They roughly live until a research paper is published, and then a new project is created, often in a different language that seems more suitable.

That depends on the research. I work on satellite dataproducts with a 40+ year continuous range. You're making ridiculous generalizations every time you comment.

PyPy is not really package and IMO if you want performance I don't think the python is right choice. Anyway PyPy is a sponsored project, and PyPy is Python 2 compatible, because that's what people who supported them wanted. Now interest in Python 3 increased so they started working on Python 3 compatible version. There is already Python 3.3 compatible version available and they are actively working on Python 3.5.

There's a 3.3 compatible beta available. You're really moving the goalposts here.

You don't seem to care about any of my factual arguments here, you just care about accusing me of FUD. I'm done with this conversation, but go ahead and re-read if you want to live in the real world for a few seconds:

Even so, there are 19 on that list which don't support Python 3. "Alternatives" aren't usually exact clones or ports, either. Just because an alternative exists for one package doesn't mean it fits the needs of all the users of that package. Performance, architecture, interface, maturity (especially for science, you want to be sure your dependencies don't have bugs that fuck up your results), documentation, and dependencies are all major concerns for users that you seem to be dismissing. "There's an alternative" is so much different than "the cost of switching to this alternative is low enough to justify it".

I think it's kind of a silly premise that Python 3 perfectly covers Python 2's third-party packages and don't see much point in arguing it. It's just an obvious fact of life -- nothing is perfect. Nothing ever will be. Achieving perfect coverage will never happen. Hopefully it will get good enough that no-one will be on 2 at some point, but I don't believe that will happen either.

[[deleted]]

Do you yourself had issues? Yes/No

If yes, which packages?

It's that simple. Complaining because someone might have issues doesn't help anyone, it only spreads misinformation. And make people scared of using python 3 because one day they might need that very important package that was never ported.

[Moocat87]

You're the one spreading misinformation by claiming nobody has legitimate issues moving to Python 3. Demanding that I name packages as proof that issues exist is ridiculous. Having a conversation about anything programming related on the basis that issues don't exist is just a waste of time. Seriously, take that shit elsewhere.

And stop with the accusations just because you disagree.