Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web development etc with asyncio whatever, but for me all I get from 3 is Unicode and xrange cruft that simply complicates my code for zero benefit. Personally am hoping that something new emerges that will take over from Python altogether as the default in data science, or that some big entity will sponsor a fork of 2.7 to shutdown this ridiculous "eol" dictatorship.
Please don't make generalizations about people who disagree with you just to score a rhetorical point, and please don't break the HN guidelines by going on about downvotes: https://news.ycombinator.com/newsguidelines.html.
So what you're saying is that Python 3 changed some small stuff that you see no benefits in, but moved a year ago, and you're now on Py 3.4. And because of that small no-benefit update, you want to move to completely different language that will start with: no scientific libraries, no community, and will likely require rewrite of everything you work with?
the benefit is that all the wasted energy that went into all the useless 3.x stuff, could have been spent on advancing Python's speed, multicore, or GPU programming capabilities. Instead, for the single use case where Python is clearly the dominant language (for pure network-effect reasons), namely scientific programming, we have been at a standstill for years. In other words, under current stewardship, Python is going down a path where I don't see a long term future for it in my domain, and therefore, I am looking elsewhere already.
I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth. This is particularly true given that Go is rapidly eating Python's lunch in all non-science use cases.
> I am also almost 100% certain that if scientific programmers leave Python, the language will stall, and the current 3.x pushers are dangerously looking a gift horse in the mouth.
This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance.
This is what is happening with Python 3 and a smaller, doom-and-gloom subset of the userbase. Most of us are thankful that Python is striving to improve, and that we continue to pay nothing to use it. The alarmists are far more noisy than those that are happily continuing to build stuff.
Python will remain massively used in the sciences. It's simple, easy to learn, expressive, and has an excellent ecosystem of modules (which now mostly work on Python 3).
>This sounds like such similar sour grapes to the systemd escapades. Huge initial outroar as certain things happened, followed by a gradual diminishing, then [mostly] acceptance.
Only here we don't have mere service scripts, but millions of lines of code people have written in perfectly fine 2.x Python.
And also here we don't have any significant uptake -- Python 2.x is still over 60% of what's used (according to PyPi stats and everything we've seen), and that's after 6+ years that Python 3 had its chances.
PyPI stats are massively inflated by automated deployments, and anyway even them show a clear rising trend for 3. Also, 3.4+ (from 2014) is a very different beast from 3.0, and it's probably not a coincidence that porting significantly accelerated after its release (about 3 years ago).
With numerous libraries phasing out support for 2.x in current or upcoming versions, I think we actually do have significant uptake.
As pointed out by others, those PyPi stats are super off. Better to look at what's going on out in the community and with the most popular packages (like Django).
Except that personally I see the benefit of Systemd every time I boot my linux computer. It just works, fast, and clean. I don't partake in the philosophical arguments. I just want it to work. Py3 by contrast, simply throws cruft curveballs at me. No tangible benefit. This is not a systemd-style issue.
And yes Python will likely continue massively to be used in the sciences, 3 bears like me notwithstanding, so it would be good if the current stewards would actually recognize the fact that this is their core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.
> core base of users and please could they focus on them instead of the web people who are much more fickle and moving already.
Ahhh, I see what's going on now. You may be vastly underestimating the size of variety of the Python userbase. This is one of the absolute most popular languages on the planet. Your science subset is but one of many. And it's not even the biggest if we're talking sheer user counts.
Python must be steered for the good of the majority of the userbase. Not just for vegabook. The fact that you described them as "useless" to me just speaks to someone being impatient and dismissive of a ton of excellent work by the contributors. These changes weren't made just for the hell of it. Particularly the Unicode example that you gave above.
If you want help understanding the rationale behind some of these changes, feel free to ask here. Someone with more familiarity will chime in and help clear up the confusion or angst.
Lol. Before Numpy and friends even existed, Python was used mostly by "the web people" and sysadmins. Scientists are one of a number of Python constituencies, and not even the best-paying nor most visible one.
Interesting that you're looking for those improvements in CPython. From your list (IMO): speed and multicore are going to stay where they are in CPython - GIL is unlikely to be removed, because it's basically part of the behaviour right now. There were a few attempts, but it seems nobody even tries anymore. (and I'm fine with that) Maybe pypy, grumpy, or others will do this instead.
I'm not sure why you expect GPU from the python itself though. That's completely up to libraries and they can exist for either 2.x or 3.x. Was there ever a CPython GPU related project?
The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.
And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.
"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.
Yeah, you are a bit condescending here. Part of the topic was multicore. If you're interested in actually cutting down the data transfers without resorting to explicit shared memory, GIL and threads are very much on topic. Whether it's an overblown issue depends specifically on your workload and reasons why you're still using python if you care about multicore.
I attended this talk, and it was really great. PyPi is pursuing software transactional memory, which is massively difficult to implement. The Gilectomy approach is much more community oriented, and focuses on the transition.
Put a bit differently: it's easy to remove the GIL safely, it just incurs a non-trivial performance penalty and breaks C extensions, so the Gilectomy effort is around a combination of removing or avoiding that penalty if you're not multi-threading, and smoothly transitioning C extensions. After that talk, removing the GIL looks inevitable.
To me, unicode alone was worth the switch. I will go to great length to avoid the hell that is unicode in Python 2.
Besides speed, I never seen any good argument that would make me start a new project on 2.7, rather than the latest v3 release. I get that there was a series of data science libraries that wasn't supported initially, but seems to have been solved at this point. So I really do see why people continue to hate Python 3.
I'm not going to argue that the transition couldn't have been handled more smoothly, the period of broken libraries and terrible performance was a little too long.
If you don't care about the Python 3 features, then don't migrate. I suspect that the issue is that you want at least some of the features, but the cost of moving 10+ years of Python 2 to Python 3 just aren't worth the benefits of those new features.
While I do believe that your point is still valid, one also have to accept that Python 2 will be a legacy platform at some point. In the long run I don't view that as much different than people complaining about Visual Basic 6 being deprecated.
Python 3.0 was released in 2008. Python 2 will EOL in 2020. You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL. A 12-year upgrade window sounds pretty reasonable.
>You've had about 9 years to start the transition to 3.0, and you still have 3 more years before EOL.
Most of those years library support was non-existent or lacking. And still today the majority uses Python 2.x (Pypi stats).
So it's not like the migration was some great success since the start, and all those years were just wasted by some minority not migrating.
In the end, it's not a discussion on HN or what the "BDFL" says about an official EOL that will settle the matter, but actual adoption in the field. But in addition to the low adoption rate, we've even seen people leave Python for Go and Node/JS.
I'm not seeing signs of these kinds of widespread issues out in the wild. The popularity of the language has continued to increase, and numerous warts and flaws were wiped out in Python 3.
That Unicode "cruft" is especially appreciated by the rest of the world that exists outside of the US. Python 2's approach to bytes and encoding is naive and horrible for 2017.
I'm outside of the US and Python 2 has worked wonderfully for ages. Its unicode support is good. You work with strings as unicode, then at I/O boundaries (and exceptions) you convert to bytes. What specifically do you find "naive and horrible" about its bytes and encodings?
Python 3 can use less memory for unicode strings (a cool optimization introduced in py3.3, IIRC), and it did away with the "narrow/wide build" distinction (same release). That's about the only every-day advantage I can think of. But I suspect that's too technical, or do you mean that?
This has been explained over and over. Those boundaries in python2 are very easy to get wrong and the runtime will not warn you, which means you won't know about them until some crap data comes down the wire and code chokes or (worse) silently corrupts data. In py3 you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible.
It shouldn't take 8 years to understand this issue, and I'm positive you do understand it because you're an intelligent person, so please don't troll about it.
"With dynamic typing, the runtime will not warn you, which means you won't know until some crap data comes and your code chokes. With static typing, you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible."
See what I did there?
toyg, I found your comment unbearably rude, condescending and arrogant, and downvoted it for that reason.
Confused your terminology? With static typing, the compiler will warn you, not the runtime.
Regardless, the difference is that in practice, file-handling boundary calls don't need to be as flexible as internal interfaces, and it's obviously much more difficult to figure out what The Right Thing To Do is in the latter case (or whether there is a Right Thing at all, in a lot of cases). How many times do you need to change the encoding you use for writing files? How many times do you change an internal class or type? They are totally different ballgames.
> I found your comment unbearably rude, condescending and arrogant
Apologies, but after 8 years and countless hours of bickering on this point, patience can wear really, really thin.
It's actually easier for people outside of US, who are forced to deal with languages that require Unicode to work properly. If you screw up somewhere, you notice right away.
But those for whom the majority of input is ASCII can often get away with broken code (that e.g. writes out Latin-1 JSON) for a while. And then they get input with a word like "naïve", and oh look, all hell breaks loose.
Python 3 solves this problem by making every transition problem explicit, requiring the developer to stop and think what they're doing when going from byte representation to strings, and vice versa.
For what it's worth, as someone who ha been working with Python for 11 years, Python 3 is a huge improvement over Python 2 and is certainly very popular with my peers.
The fact that you personally weren't particularly affected by the problems in 2 doesn't mean the problems weren't serious.
