But for the newbie user it's a nightmare. If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+).
Not to mention pip and package management - which compared to ruby, is just terrible. I mean there isn't even an update all command in pip. And of course if you have different versions of python you have different versions of pip. With different version of packages installed.
And now for virtualenv. Ok great tool. But even in this area there's confusion. Different people use different environment managers. And virtualenv isn't the easiest thing to setup - from a new users point of view. Where in ruby there's gem. It's installed with ruby. Period.
The community isn't doing itself any favors by dragging their feet. Everyone should jump onboard the python3 wagon. And if you need a package that isn't 3, then rewrite or look for something else. Maybe if the maintainers of said packages knew that their users weren't gonna stand for not supporting version 3 they'd get off their butts and convert - or release the code and let the community convert the package for them.
> If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+).
That's because these are all still valid versions of Python (which are still shipped with OSes). Most of the concepts you learn in Python 2.5 are still valid in Python 3.3; the changes weren't that dramatic. There are still strings, the control mechanisms didn't change, logic still uses the same operator precedence, the syntax didn't change...
Yes, there are now byte and unicode strings (as there were in Python 2), yes, print is now a function, yes, a few functions now return iterators instead of lists, and yes, a few functions/packages were renamed. Pretty minor changes, in the long run; breaking changes yes, but still minor for all that.
> Everyone should jump onboard the python3 wagon.
No, they shouldn't. You should never risk your production critical code just because a language wants to evolve. Perhaps this is a difference from Ruby (particularly Rails) where there appears to be an "evolve or die" philosophy, whereas Python says "we're here when you're ready, but we're not going to ignore you". It honestly makes me happy to work with Python, where I don't have to chase down a production fire because a developer decided to make a breaking change.
I will personally move to Python 3 when it's prudent to do so - when the environment I develop for supports it natively. Until then, I'm glad I'm not being forced to move ahead. It makes my day to day life as a developer simple.
I wish it were true that existing online materials are appropriate for both Python 2 and 3.
It's true that experienced Python programmers can easily identify the distinctions, and thus translate back and forth in their minds.
But for a newbie, the fact that print("abc") works on Python 3 and 2.7, but not on earlier editions of 2 (and yes, many people still use those earlier versions) is confusing and frustrating.
When I teach my Python classes, I always tell them that they should check a tutorial, blog post, or Stack Overflow answer before using it, to see if it's relevant to Python 2 or 3.
Might I be so bold as to recommend not using print in the first place? Print's behavior changes depending on the environment, the capabilities of your terminal, and if you're piping to something else.
Instead teach people how to use sys.stdout to get properly deterministic behavior.
Print is useful in the repl, and in quick one-offs, but I would never use it for production deployments. And I never let it survive a code review either. It's bad practice to rely on it.
It's better in Python3, but I'd still probably use explicit file streams.
You're always going to have old documentation on the Internet (and it's a good thing!). The more annoying problem I encounter (not Python specific) is blog posts or news stories without publish dates.
All of the Python communities I've seen have a "Python 2 or 3?" section that's pretty clear--"depends on what you want to get done. Python 2 is most widely deployed. Python 3 is complete but lacking an install base and library support." I've written a small amount of code in Python 3 and they're not that different.
I entirely agree about package management (and virutalenv). It finally appears they have a way forward with package management. If that's implemented in Python 3, it'd be a significant reason to adopt. Virtualenv is already part of Python 3.
At my workplace, we're still transitioning from Cent5 (ships with Python2.4, but we're using 2.6) to Cent6 (ships with 2.6). Our third-party packages are still on 2.6 and the newest versions of them are finally using 2.7. So we've brought up Python3, but are still just talking about moving to 2.7. I, too, wish adoption of Python3 was faster, but even if there were more enticing features my workplace is beholden to the platform we're using. I think now that newer distros default to Python3 is fantastic, and it will take the long term versions defaulting to them before most companies are convinced to switch (still a few years off).
Not to mention pip and package management - which compared to ruby, is just terrible. I mean there isn't even an update all command in pip. And of course if you have different versions of python you have different versions of pip. With different version of packages installed.
And now for virtualenv. Ok great tool. But even in this area there's confusion. Different people use different environment managers. And virtualenv isn't the easiest thing to setup - from a new users point of view. Where in ruby there's gem. It's installed with ruby. Period.
The community isn't doing itself any favors by dragging their feet. Everyone should jump onboard the python3 wagon. And if you need a package that isn't 3, then rewrite or look for something else. Maybe if the maintainers of said packages knew that their users weren't gonna stand for not supporting version 3 they'd get off their butts and convert - or release the code and let the community convert the package for them.