Python 2.x vs 3.x use survey(surveymonkey.com)
surveymonkey.com
Python 2.x vs 3.x use survey
https://www.surveymonkey.com/s/N5N5PG2
118 comments
That was opened five years ago, bizarre.
Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?
Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.
Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance.
I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere. And again, it's a lot of work with no huge payoff.
>It's more work than it appears.
I completely believe that, and good point about Python 2. I wasn't considering that side of things.
Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)
I completely believe that, and good point about Python 2. I wasn't considering that side of things.
Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)
Come join us in #mercurial in Freenode or in [email protected] if you're interested in solving this problem.
"Do you think Python 3.x was a mistake?"
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
- 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.
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 just stumbled on PyMySQL[0], who supports Python 3. Is there any issue with using this library, since it seems an obvious solution to this problem?
[0] https://github.com/PyMySQL/PyMySQL/
[0] https://github.com/PyMySQL/PyMySQL/
oh please.
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)
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)
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?
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.
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)
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.
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.
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.
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.
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.
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.
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).
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).
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!
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.
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.
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.
Dear Apple. Please include python 3 as /usr/bin/python3 in all future Releases. And Microsoft, if you're listening, it would be extremely sweet if you would install python by default as well...
Microsoft would prefer you to use PowerShell and Visual Studio. Python wasn't invented in Redmond.
Yes, well, that's why I said it would be sweet of them. You know, like, a grouchy old military dad taking his daughter to see Snow White. It may not he his choice of entertainment, but it's very sweet of him to take her. :-)
They did have a Python implementation for a while (IronPython)
If anything, they would package IronPython - which wouldn't go over to well with people expecting C-extensions to work.
Would be cool to include latest Mono into all major *nix distributives as well.
The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...
Those things return generators now to avoid wasting memory (you don't need to create possibly humongous list and keep it in memory during the iteration). If you want a list, just do list(your expression). If you forgot about it then do: list(_) as the very next thing. Like this:
>>> map(lambda x: x*x, range(1,10))
<map object at 0x02DDDB90>
>>> list(_)
[1, 4, 9, 16, 25, 36, 49, 64, 81]
Wtp ?
>>> map(lambda x: x*x, range(1,10))
<map object at 0x02DDDB90>
>>> list(_)
[1, 4, 9, 16, 25, 36, 49, 64, 81]
Wtp ?
Yeah, it's definitely something that can be worked around, but it's something I don't have to get around in python2, so I keep using python2. Nothing truly major, just a sticky point.
> The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators.
If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.
If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.
[deleted]
This. Not all generators can be converted to a list in a timely manner, seeing as infinite generators are supported.
Neither does Python2.
$ python
Python 2.7.5 (default, Aug 25 2013, 00:04:04)
>>> xrange(10)
xrange(10)
>>> list(_)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]You are definitely correct; it's really the combination of py3 using generators more frequently (which is a definite good thing) with the py3 repl not evaluating them that keeps me going back to py2 for my repl needs. A more fair comparison is with ghci, which expands thunks and runs IO actions when functions return them. As others have pointed out, this can be "dangerous" in the sense of flooding your console with crap (try typing [1..] in ghci; its' annoying, but not the end of the world either), but it's also really convenient when that's what you want. The python2 repl/functions do what I want, and the python3 repl/functions don't, or at least don't often enough that I keep going back to python2 for all my repl needs. Just a random chunk of anecdata, I guess.
It's really only a solution if the calculator usage is on a small number of computers, but you can just import * an override of the map function that behaves however you want.
The override is easy:
The override is easy:
pymap=map
def map(...)...
You don't even have to do the assignment at the begging of your snippet. You could just refer to the builtin module explicitly.
Write it as a list comprehension instead; it has identical syntax except for using square brackets instead of parentheses, and returns a list.
A list comprehension would work for GP, who wants a calculator. But others like to try out snippets of code in the REPL before using them in programs, and in that case you want the code to be the same.
Would the following work? It's been a while since I've had Py3 installed, so I can't casually try it. In your PYTHONSTARTUP, place the following:
Would the following work? It's been a while since I've had Py3 installed, so I can't casually try it. In your PYTHONSTARTUP, place the following:
_map = map
def map(f, *args):
return list(_map(f, *args))
[deleted]
Consider a generator that yields results indefinitely, or even merely millions of results. Are you still sure you want those printed to the repl? :)
That is the approach that Haskell takes. If the repl responds to ^C by aborting whatever line it was evaluating then infinite results are little more than annoying, and you quickly learn to restrict what it prints to the first few elements (in python this would just involve appending [:n]). Ultimatly this is a question of which uses you want to optimize. Personally, I find Haskell's approach more useful as a calculator.
A middle ground that I have not seen is automatically evaluating the first few elements and showing those as part of the <object> output.
A middle ground that I have not seen is automatically evaluating the first few elements and showing those as part of the <object> output.
The Python interactive shell could check the user's input: If it'll take infinitely long to run (e.g., an infinite generator), then it'll halt. If the code will eventually return, then it'll be run, displaying results to the user. Seems simple enough, no?
You'll need some killer heurstics: https://en.wikipedia.org/wiki/Halting_Problem
Only reason I still use 2 over 3 is that 2 gets the job done, is well supported and I don't see a big enough reason to move to 3. If 3 had a big performance increase, then maybe I would switch. Anyhow, I'll probably move to 3 at some point just because at some point more people use it (more code on the Internet in 3, more StackOverflow answers in 3 etc.)
The survey is missing sets of answers for users who rejected or moved away from python because they were turned off by the disconnect between core devs and the community when python 3 got released.
I can't say I understand this attitude. It's analogous to cutting off your nose to spite your face. Both Python 2 and 3 are actively supported, and there's a clear migration path defined. The migration isn't complete yet, but it's progressing at a development friendly pace.
I say this as someone still on Python 2.6 due to environment restrictions.
I say this as someone still on Python 2.6 due to environment restrictions.
The migration is so difficult that you might as well migrate to a different language and solve the speed and memory usage issues while you're at it.
What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage?
Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department).
Ruby? Same speed and memory "problems" as Python.
Perl? Faster, but its language design philosophy is diametrically opposed to that of Python.
Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.
Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or `<` operation) and feels a lot more like writing C than Python (not to mention its lack in the "batteries included" department).
Ruby? Same speed and memory "problems" as Python.
Perl? Faster, but its language design philosophy is diametrically opposed to that of Python.
Clojure/Haskel? Syntax and program structure are so radically different from Python there's no comparing them to Python3 when discussing differences from Python2.
I'm actually leaning towards Haskell and Clojure these days. They get me more of the simplicity that Python won me over with along with other benefits.
I gave Go a chance to supplant Python as my main language, and I thin it could do that. I had a few other problems with Go though which led to me looking at Haskell.
I'm giving Haskell a chance to supplant Python/Go as my "go to" language atm and it seems to be winning me over, but only time will tell.
I gave Go a chance to supplant Python as my main language, and I thin it could do that. I had a few other problems with Go though which led to me looking at Haskell.
I'm giving Haskell a chance to supplant Python/Go as my "go to" language atm and it seems to be winning me over, but only time will tell.
I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement.
The same cannot be said for the multitude of changes to Python.
The same cannot be said for the multitude of changes to Python.
I use/used Go for a while, but early on I thought the type system was stronger than it was. I was disappointed in a later project, and started looking at languages with stronger type systems.
I came across Haskell and Hindley Milner ;)
I believe Haskell replaces Go for me and with some experience (when I can picture types in my head better) it will replace python as my go to dynamic language.
I came across Haskell and Hindley Milner ;)
I believe Haskell replaces Go for me and with some experience (when I can picture types in my head better) it will replace python as my go to dynamic language.
Go would be my first recommendation. The strictly enforced coding habits, lack of generics, the packaging system without dependency versioning and quirks like typed nil are a small price to pay for the sane syntax, impressive performance and a very easy to use CSP implementation.
P.S.: I don't know what you mean by that example. You don't need to cast an int to anything in order to use comparison operators.
P.S.: I don't know what you mean by that example. You don't need to cast an int to anything in order to use comparison operators.
Well, get over it and understand it...
Speaking personally, I sought to move away to a utf8-friendly language from php a few years back, and seriously considered Python back then. It came highly recommended on Stack Overflow.
Upon investigating the matter further, however, it became clear that the community suffered greatly from the divide introduced by Python 3. As if the core devs went in one direction while the community at large went in another.
It wasn't exactly a welcoming place for a newcomer. As if you needed to pick sides on day one. I ended up selecting another language and have never looked back.
If anything, I'm bemused that the debate still rages on years later. And I can readily picture seasoned Python users being put off by the same, and looking elsewhere for a saner ecosystem.
Case in point: As some have already hinted in the thread, the point is becoming moot nowadays, not so much because the community is slowly making the switch to Python 3, but because community members are moving en masse to Node, Go, Scala, Clojure, etc.
Speaking personally, I sought to move away to a utf8-friendly language from php a few years back, and seriously considered Python back then. It came highly recommended on Stack Overflow.
Upon investigating the matter further, however, it became clear that the community suffered greatly from the divide introduced by Python 3. As if the core devs went in one direction while the community at large went in another.
It wasn't exactly a welcoming place for a newcomer. As if you needed to pick sides on day one. I ended up selecting another language and have never looked back.
If anything, I'm bemused that the debate still rages on years later. And I can readily picture seasoned Python users being put off by the same, and looking elsewhere for a saner ecosystem.
Case in point: As some have already hinted in the thread, the point is becoming moot nowadays, not so much because the community is slowly making the switch to Python 3, but because community members are moving en masse to Node, Go, Scala, Clojure, etc.
Missing a question. "Would you switch to python 3 if they brought back the print statement"
Edit: I really just like the statement for the interpreter, and IPython Notebook. To me the statement syntax feels less like programming, and more like using a computer.
Edit: I really just like the statement for the interpreter, and IPython Notebook. To me the statement syntax feels less like programming, and more like using a computer.
Personally, I prefer function. I can understand that others have a different preference; what I find surprising is the number of people who seem to care so much about this. Nevertheless, it is very evident that you are not alone.
I prefer it as well. Being able to do things like throw
print(<SOMETHING I'M TRYING TO DEBUG>) or
I don't mind the print statement/function thing but I am bothered by the pain when dealing with byte strings. I use Python to talk to hardware that doesn't speak unicode, the contortions I have to go through to get byte strings to behave correctly on py3 are frustrating. I have no problem with the default string being unicode, but why can't byte strings be implemented like the unicode strings were done on py2.x?
What's the specific issue? I find it solves loads of issues before where you could mix bytes and unicode by accident. Not only are they more explicit, I find the fact that `b'\0'[0] == 0` - way better when working with actual bytes.
The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.
What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2.
Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?
Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?
See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings
I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text)
But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)
But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)
[deleted]
As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene.
Explicit is better than implicit.
Explicit is better than implicit.
Is there some story behind it? It looks like the smallest issue out of the whole migration. (especially with from __future__ import print_function)
I think people would prefer "from __past__ import print_statement" in 3.x.
That's why I'm asking really - not only those two would be pretty much equivalent, there's really nothing that can be expressed with one, but not the other. I mean that's kind of like saying "would you use it if they called the binary snake instead of python3" - what's the reason apart from personal preference for the syntax?
Why the hell?
I don't know, but it bugs people. https://news.ycombinator.com/item?id=6987309 https://news.ycombinator.com/item?id=6985792
I would hazard a guess that it is because the statement allows for easily adding a `print varname` in your code while debugging.
print(varname) is one extra keystroke -- and a whole more convenient than a statement when you want to do it in a lambda for debugging.
What is the advantage of python 2 print over python 3 print? I believe that python 3 print can do everything python 2 print can do on the same level of elegancy. Also, python 2 print has a weird trailing-comma syntax. When a trailing comma is added to a print statement, a space is printed when another print statement is used. For example,
print 'hi', # prints hi (no extra space in the end)
print 'hi',; print 'hi' # prints hi hi
I personally dislike this syntax because I don't find this natural. Wouldn't it make more sense to print an extra space after the print statement with trailing comma instead of before the next print statement?
print 'hi', # prints hi (no extra space in the end)
print 'hi',; print 'hi' # prints hi hi
I personally dislike this syntax because I don't find this natural. Wouldn't it make more sense to print an extra space after the print statement with trailing comma instead of before the next print statement?
no trailing space is a convenient shorthand - print by itself prints with a newline (so it might make sense to have print() vs println()); print + comma omits the newline and waits for the next print statement, so that
print 'hi',
do_something()
print 'there'
print 'hi', 'there'
hi there
FWIW:
pprint = functools.partial(print, end=' ')
pprint('hi')
do_something()
print('there')
print('hi', 'there', sep=' ')
fprint = functools.partial(print, file='/var/log/foo.log')
fprint("I'm writing to a file!")
fprint("So am I")I understand this, but couldn't you simply wrap print itself in a function, and do that in Python 2.7 already? Granted, your method saves you one line and it's more 'natural'.
Not really, since the Python 2 version is a keyword, and not a function, you can't simply provide keyword arguments to it. You would instead have to build up a string and eval it. It would have to be something like this (completely untested):
http://docs.python.org/2.6/reference/simple_stmts.html#the-p...
def print_wrapper(*args, **kwargs)
outfile = None
print_stmt = "print "
if 'file' in kwargs:
outfile = open(kwargs['file'], 'a')
print_stmt += '>>outfile '
print_stmt += ", ".join(*args)
if 'end' in kwargs and kwargs['end'] == ' ':
print_stmt += ','
eval(print_stmt)
if outfile is not None: outfile.close()
http://docs.python.org/2.6/reference/simple_stmts.html#the-p...
It would be nice if we could see the results
Where are the real-time results? :)
In my view, the importance of the 2 vs 3 issue depends on who you think the typical Python user is, and the user population may be changing rapidly.
I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"
Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.
I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.
I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"
Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.
I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.
I may be old, but this just reminds me of Larry Wall's Perl 6 and in my opinion Python 3 should have been a hobby project / incubator for changes that could be introduced to Python 2 eventually.
I'd also like to see the results. Curious, did you create this survey to see if there would be interest in a long-running Python 2.x fork?
IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.
I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.
IIRC the Python community was already expecting a fork to happen eventually (because 2.7 is the "final" 2.x release) so getting the community involved would be a good thing.
I would imagine that the purpose of maintaining 2.x would be for fixes, security, and back-porting of features that make it easier to have 2.x and 3.x-compatible code.
Results from this survey can now be found at
https://wiki.python.org/moin/2.x-vs-3.x-survey
https://wiki.python.org/moin/2.x-vs-3.x-survey
A wise man once said, http://www.aaronsw.com/weblog/python3
I'm curious what the Python 3 adoption status is inside of Google, which I think of as a place that's relatively pro-Python, very pro-new stuff, but also possessing a lot of institutional inertia and giant amounts of code. Have parts of Google overcome the inertia and switched to 3? Do fights break out in the halls? Is it 2 forever and always?
I don't think people realize how easy it is to run a Python2 and Python3 codebase at the same time if you have decent test coverage and run tox.
Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.
Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.
I don't really have a strong reason to prefer 2.x, but I'm stuck on it as I mostly (exclusively) use Python on Pythonista for iOS.
But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!
But I'm fascinated by the debates over the merits of the two. Thanks for posting the survey!
There was a dynamic graph somewhere showing the number Python 3 and Python 2 packages on PyPi against time, no amount of googling can find it, does anyone know what I'm referring to? I'd love that link.
Do you mean the wall of shame/superpowers?
https://python3wos.appspot.com/
https://python3wos.appspot.com/
Nope, there was a graph, though that is interesting too. I'm actually quite impressed with how green it is!
From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.
The NLTK site says the Python 3 version is still alpha.
My only question is... does Gunicorn+Gevent work on Python 3 yet? Last time I checked one worked and the other only had a branch which you could use but wasn't in master yet.
http://bugs.python.org/issue3982
They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work.
The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python itself is hosted with hg. :-/