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.
I don't think it's a leading question - I think if they get a large enough sample size, it will be a worthwhile survey of the Python community's 2/3 behavior.
Ultimately, you did pro-Python 3 supporters a disservice by not speaking up.
I suspect the survey is probably selection biased towards 3 as it is. In any event, whether respondents considered it a mistake or not, it's a mistake.
I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea."
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.
It's way way way higher than 50%, if my sample is accurate.
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.
Being a newbie at Python myself and seeing how much the Python devs are trying to get people using Python 3, I was initially planning on just using Python 3 for all my Python coding. That was until I realized how many libraries exist only for Python 2.
Why not the question "Is staying on Python 2.x a mistake?"
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.
I agree that the survey is poor, but it is not bunk.
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.
Depends on how you interpret "mistake." I don't think that improving the language is necessarily a mistake, but the way they did it is a mistake. It should have been an absolute requirement that, one way or t'other, a user could employ 2.x libraries transparently. No change should have been allowed until and unless a way was found to make it not impact backward ecosystem compatibility. This is a law of nature that was ignored and 3.x is paying the price that anyone could have predicted (and most did.)
Not ensuring library compatibility was lazy, egotistical arrogance and will ultimately relegate 3.x to being a historical footnote.
I really wish there was an "undecided" option for that particular question. I said "yes", but only because I think having backward compatibility trumps cleaning the language up.
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 wouldn't, not yet. There's not enough support. Great ideas, but the support isn't there for it yet: not in libraries, not in operating systems, not in documentation.
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.
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).
This isn't actually true anymore for many, many things:
- 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
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?
No, if it is a library, that you use all over your code. And you will not risk that your project fails, just because somebody wants to use only the newest stuff. Nobody in a time critical project (when it is not?), will switch from Py2 to Py3 just because it is the most recent version of Python and replace at least one library that is written in C and does not work in Py3. Either you have to replace the whole lib or you have to port the lib itself (what is not easy, when you don't have an experienced extension coder in team -- and also than, it is a risk!).
But the GP comment wasn't just addressing porting projects (which I would understand), it was "one single dependency that doesn't support py3 is the death knell to using it for anything, EVER" (emphasis theirs).
That's a fairly strong opinion to take, and in my opinion, goes far enough to be ridiculous.
When you have the option of starting a project with py2 or py3 and you choose py3, and discover X days into the project that you have a broken dependency that wouldn't have been broken in py2, you've just increased the cost and time to deliver the project by an unknown factor.
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)
When you have the option of starting a project with py2 or py3 and you choose py3, and discover X days into the project that you have a broken dependency that wouldn't have been broken in py2, you've just increased the cost and time to deliver the project by an unknown factor.
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.
Its all well saying Django supports Python 3, but when you reply on a dependency, such as MySQL connector (which I assume a LOT of Django users will want to use), then Django effectively doesn't work with Python 3.
I have problems with the way this is worded as well. I don't think Python 3.x was a mistake. I think the mistake is continuing to develop it in parallel with 2.x with no definitive end of life for 2.x is the mistake.
No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it)
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!
Setting an end of life for Python 2 would be the forcing function needed to ensure Python 3 is reliable and the migration path is clear. Knowing the end is coming would drive us (the community) together to discuss and resolve these issues.
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.
Even than, I doubt that it would be helpful, since still so many C extensions are just not available in Python 3. I also don't think that it is a problem of apathy, but of wrong initial planning. With better initial compatibility, a bigger momentum could be reached. Now the decisive point is over and we will have to live long with both versions around (even when Guido sets a date).
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.
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.