[bmoresbest55]

Python is very much an established languages and myths like these need to go away in order for people to feel comfortable using python for serious, well designed projects that scale and do every and any thing that a person may want or need. Great post.

[baldfat]

I agree BUT... Python 2 and Python 3 migration is still a major issue. It has come a LONG way in the last 18 months.

Also Python is good at thing but

> feel comfortable using python for serious, well designed projects that scale and do every and any thing that a person may want or need

Might be a little to bold of a statement :)

[coldcode]

As a non Python programmer, is 3 the way to go for all new projects? Or is there some advantage to 2 still?

[bjacobel]

There is no advantage to 2 unless you're using a legacy environment or a legacy dependency.

Edit: the "Python 3 Wall of Superpowers"[1] is a good resource for seeing how far the ecosystem's conversion to Py3k has come. Many of the "red" packages even have Python 3-compatible forks (e.g., Supervisor).

[1]: https://python3wos.appspot.com

[crdoconnor]

There are still a lot of libraries which haven't moved yet.

I periodically check my requirements.txt's and there's still a few big holdouts left.

[rspeer]

Which are they?

I know that python3wos is out of date regarding the libraries people actually use. When I look at the py2-only libraries on there, I see:

- the big "legacy dependencies", Twisted and gevent

- libraries that are ported but the site doesn't know it, such as protobuf

- highly specific code to extend a particular system, such as tiddlywebplugins

- system utilities that it doesn't matter what language they're in, such as supervisor and Fabric

- libraries that have been abandoned (in all versions) and superseded, such as MySQL-Python

I'm not saying you're wrong, I'm saying that we need a better python3wos. It makes it look like "unless you bet on a massive legacy asynchronous framework, you're fine".

I think that to some extent this should be the case, but to some extent, there are things that should be ported that we're not seeing because of the unrepresentative set of packages on python3wos.

[crdoconnor]

Twisted is one, and it's there partly because a lot of code relies upon it, not because I like it. I also use a few niche libraries which haven't been bumped and there's a few libraries like mechanize too - not so niche yet still not bumped.

Honestly, if there were some big incentive at this point I would go through the hassle of upgrading, but there isn't. The gains on python 3 seem relatively minor and incremental.

[squeaky-clean]

The only major reason to use 2 instead of 3 is library support, however a lot of good libraries still aren't updated to Python3, such as the google-api-python-client, gevent, scrapy, the list is getting smaller every day though. There are a few other reasons, but they're pretty uncommon/advanced, and not something new users will encounter [0].

Python 2 gets many of Python 3's features back-ported (they can be enabled with an import statement), which is really convenient when working with 2, but it also helps contribute to the lack of a migration from 2 to 3.

Python 2 and 3 are very similar though, and most projects can even run under either 2 or 3 with the exact same codebase. So it doesn't take much effort (or none at all) to move a project from 3 down to 2 while still in early development if requirements necessitate.

[0] One example that comes to mind is a difference in the way str.format() works. In Python 3, strings are unicode text objects, in Py2, they are bytestrings. Some projects used str.format() in Py2 to format binary data rather than text, which breaks when moving to 3. Porting a compatible change to Py3 has been rejected several times because of the complexities in implementation, as well as it being unidiomatic to the language. See:

https://bugs.python.org/issue3982

[creshal]

There's still a bunch of libraries/frameworks that only work with python 2. If you don't expect to be needing those, python 3 can be safely used.

[xorcist]

It depends on your problem domain. If it's Ansible-related for example, you go with 2. If it's web related, 2 is a good default, as those are still the most tested code paths. If it's scientific, go with 3, most of those tools are newer.

[dagw]

If it's scientific, go with 3, most of those tools are newer.

Which tools? I use python for scientific computing and I can't think of any tool that I use where the python 3 version (if it exists) is newer/better than the python 2 version.

[baldfat]

numpy and pandas are both Python 3.

Newer and Better is a totally different question and this is why we have the Python 2 or 3 debate.

[dagw]

Sure, but as far as I know numpy and pandas for python2 and python 3 are exactly the same. I don't think there is a newer python 3 version of either.

[scarygliders]

I would definitely recommend learning with 3 and going forward from there.

Python 3's library is growing all the time and in my opinion already has all the libraries or bindings you'll need right now.

[frownie]

If you need unicode (i.e. your app will take more langauges than english and spend a lot of time on that (hint! GUI hint!), the 3 is the way to go. Unicode support is so much better...

For the rest, it depends on the libraries you need...

[Alex3917]

> It has come a LONG way in the last 18 months.

Google actually just started supporting Python 3 last week, and they were one of the last big holdouts.

[bmoresbest55]

It may be bold but why not be a little bold now and then.