That's where I stop filling out the survey.
And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.
Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.
It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.
I've been teaching Python in China, Europe, Israel, and the US for years. In the last four years alone, I've taught about 2-3 Python courses (usually intro, but sometimes advanced or on specific topics) each month, at companies like Apple, Cisco, Intel, and SANDisk.
In only one case did a company ask me to teach them Python 3. The rest of them ask specifically for Python 2. In some, more advanced and unusual cases, they ask me to describe the changes that will happen in Python 3. They all have legacy code in Python 2 that they cannot imagine upgrading, mostly because there are libraries (internal or external) holding them back -- and the benefits aren't obvious.
(I should note that almost none of my courses are at startups. So it's quite possible that I'm seeing a sample of large companies, which are inherently more conservative than smaller ones.)
I thought that the survey was fine. But really, there's a problem in the whole Python 2/3 split, and while I've convinced myself over the years that people are switching, I've rarely met any of them. Which is really too bad.
The whole survey is bunk. Too much misinformation and misbeliefs regarding Python 3. The only valid informed answers would be from those who've used (or used and failed) >= Py3.3 for something significant.
It should have had more questions attempting to discover why those who don't adopt Python3 don't. Then, if a major problem turns out to be misinformation, it could be addressed with evangelism. If a problem is a shortcoming of Python3, that shortcoming could be addressed. Etc.
Not ensuring library compatibility was lazy, egotistical arrogance and will ultimately relegate 3.x to being a historical footnote.
It's like any software project. It's always tempting to throw everything out and start fresh, but that always takes about 100x more work than what is budgeted for.
I don't think Python3 was a mistake, but the migration is going to take time. Cutting off either group would have been a terrible decision, and I'm glad they didn't.
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.
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.
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.
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.
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).
- The major scientific/numerical packages support Python 3 (pandas, numpy, scipy).
- The best database library supports Python 3 (SQLAlchemy)
- A substantial fraction of important support libraries support Python 3 (e.g. lxml, PIL/pillow)
- Django supports Python 3
I'm honestly a little confused by people who claim that library support for 3.x "isn't there yet". My entire office has switched to Python 3 for everything.
one single dependency that doesn't support py3 is the death knell to using it for anything, EVER
I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed.
(we use pyramid not django for what it's worth)
Can't you logically extend that across language boundaries, and if so, why would you ever try to use a different language? A needed library or feature of a library might be missing.
Is it really that hard to take whatever dependency isn't supported and patch it? Isn't that one of the benefits of running an interpreted language?
That's a fairly strong opinion to take, and in my opinion, goes far enough to be ridiculous.
Perhaps for some projects, that factor is small.
...and for some of them, it turns out to be huge. So big you have to roll back to py2, and suck it up for lost time/money spent doing so.
When you have a project that is time/cost critical, that risk is absolutely unacceptable.
If you're working on your own projects, in your own time, sure thing. ...but professionally, on project work? No. Never.
Until you get the reverse, where continuing to work in py2 introduces an equivalent risk, because new libraries are 'py3 only', there is no justification whatsoever for using python 3.
Worse, because of this, when you're writing libraries, you have to make your py3 code py2 compatible, which means using the syntax-feature subset that works with py2, which basically defeats the entire purpose of migrating to py3.
Kivy is great example. The next version is going to support py3; great! ...but it's going to continue to natively support py2 on the same code base; ie. no new python 3 features. It will simply 'work' under the python 3.X interpreters.
That's why I will probably not end up using python3 in any professional work for the foreseeable future.
(If you think that's ridiculous... what can I say? Clearly you haven't worked under time/cost pressures where you have to be personally responsible for delivering on time and budget)
But you can easily replace py3 in this sentence with any other programming language. Does it still hold true? I think that's worth looking at, as groups have both successfully and unsuccessfully started projects in other languages than the core one they've been using. There are examples here of varying degrees of similarity, why not examine them?
When you have a project that is time/cost critical, that risk is absolutely unacceptable. If you're working on your own projects, in your own time, sure thing. ...but professionally, on project work? No. Never.
Obviously there will better and worse project candidates. High pressure, cannot fail projects are not good candidates. I think any company that consists only of high pressure, cannot fail projects is not very well managed. Hopefully yours is not like that.
Until you get the reverse, where continuing to work in py2 introduces an equivalent risk, because new libraries are 'py3 only', there is no justification whatsoever for using python 3.
Ostensibly, there are reasons why py3 made changes. Those reasons may still apply. Whether you think they are justified, or worth concern, is up to you.
(If you think that's ridiculous... what can I say? Clearly you haven't worked under time/cost pressures where you have to be personally responsible for delivering on time and budget)
Let's see, you make a clearly hyperbolic statement, and when I call it out, you resort to an ad-hominem regarding my credentials. I see where this is going.
I only responded originally because your statement was ridiculous on it's face, and you keep making more of them. You seem to traffic in absolutes, and general absolutes, not just for yourself; "...death knell to using it for anything, EVER", "...but professionally, on project work? No. Never." Here's a hint, all it takes to disprove never is once.
I thought I could pull some interesting information out of you as to why you held such strong convictions regarding py3 (not because I'm an advocate, I don't know/write python), and compare those reasons to how other people and groups justify exploring other languages at work, because it interests me, even if I'm generally of the opinion it's not worthwhile.
Obviously you care a lot about this, at least at the moment (at least I hope that explains why you are throwing around words like "never"). Perhaps in the future when you're less emotionally invested you'll be able to step back and look at the issue again, and maybe you'll see it the same way, maybe not.
CyMySQL and oursql are also viable options.
The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You will loose also many friends (like myself).
There was a blog post recently and stated an other option: Bring Py2 and Py3 nearer together to make the switch easier -- than more people would willingly move.
Some obstacles for moving where removed -- but a little late (e.g. the u"-Syntax was used many times in Py2 (at least outside english speaking countries or where localization is a topic) -- but abandoned in Py3. That was not necessary, but blocked an easy migration, because there are so many positions the code can be in. Now Py3 also supports the syntax and just ignores it ... why was that option not taken in the first place???) and not all. As much I know, there are still major differences when programming C extension libraries .... that makes porting existing libraries unnecessary troublesome.
Such things where not recognized early enough and still hamper adoption of Py3. Remove the blocks and you will gain more ground!
I for one never even considered that C extensions would be a serious road block. Which is obvious now that you mention it. And my main point, I've never bothered to research moving to Python 3 because there's no sense of urgency.
If Guido set a date, say Jan 1st 2015, it would remove allot of the apathy we're currently seeing.
Only thing that could really help, I think, would be a really big improvement in Python 3 that makes it more attractive to move, but that could also widen the gap between the two.