4 ms·
Speaking as a scientist: the reason for me is that there are lots of breaking compatibility changes in exchange for very little benefit. The only improvements I
by xaa 14y ago
Speaking as a scientist: the reason for me is that there are lots of breaking compatibility changes in exchange for very little benefit. The only improvements I would care about -- fixes to the bad GC and broken concurrency system -- weren't and still aren't on the table.
- xyproto 14y agoI experienced the same deficencies using Python 2 and Python 3 for years in projects at work. If you're just even a bit like me, you should find much delight in the programming language Go.
- xaa 14y agoYes, there are lots of languages -- for example Go, Clojure, and even C++11 -- that are better languages in their own right and have also solved the concurrency problem well enough. Unfortunately, scientific programming is highly dependent on libraries. So, in my field (bioinformatics), I'm basically constrained to Python or R. Python is the less shitty of the two. You can see how thrilled I am about this situation.
- stcredzero 14y agoWhat about a way of calling out to Python and/or R libraries in Go? There's already such a beast for Calling to Python from Lua.
- riazrizvi 14y agoPython 3 is a cautionary tale for enhancing a language. Break compatibility to prioritize Unicode, change behavior of widespread calls like .keys()/.values()/.items(), and make comparisons more rigid. Each of these is a major alteration in the language and should have been done right, one-by-one over multiple releases. The case for each needs to be better understood, and the enhancement can be tailored to suit that group without impacting others. Let's continue the 2.x branch where the rule must be enhancement-with-backward-compatibility, until the two branches meet at Python 4.