161–170 of 264 posts
Earlier quoted context omitted.
Compare these instead: for i in range(n): yield i yield from range(n)
Both seem quite readable, really. Seems similar to the usual "list comprehensions vs. for loop" arguments; to which I always think "use whichever is readable for the given code".
Earlier quoted context omitted.
It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Breaking code like this was a big mistake in my opinion - it resulted in many people sticking on the old version for code and library compatibility. There are still libraries which don't work on Python 3, though now fairly few of them. In addition to that, the unicod…
> It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Ruby released the source-incompatible Ruby 1.9 just months before Python 3. IIRC most versions of Swift have been source-incompatible with each other. Even a language as buttoned-down as C++ has made source-incompatible changes[1]. I have no idea where people got t…
Python3 is good, but should have happened as a smooth transition from python2.7. The way it was handled was just a mess, and still keeps polluting the Python world.
Next time somebody asks what Java has over Python... here it is: nothing like the python 2 vs 3 mess.
Earlier quoted context omitted.
> This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.
if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you. mypy is a much better type system than Java, btw, if that's what you're after.
I'm impressed how much Python seems stuck on older versions. What went wrong?
Because after nearly 10 years this mediocre list is the best they can offer as consolidation for breaking your code, and for much of that time they didn't have everything it does now. If py3k shipped with something like https://gregoryszorc.com/blog/2017/03/13/from-__past__-impor... there probably would have been more uptake.
Earlier quoted context omitted.
It wasn't broke and they fixed it. Python 2 is a mature language with a robust ecosystem. Those just don't go away no matter how much developers nag people to upgrade.
Except it was, and badly. Unicode support reached sanity matching Java or C#, if only just, but for me the most important fix was making exceptions actually work instead of being a broken pile of workarounds glued together with ambiguous and/or confusing syntax.
Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.
Ruby 1.8 to 1.9 was a similar mess for a shorter period of time, and not because it was handled better, but because there was less diverse entrenched code and subcommunities to deal with: when Rails and popular Rails libraries worked, most of the community could move; Python had a whole lot more that had to be addressed, the curse of it's broader success. (Also, being already expression-oriented, Ruby didn't have to…
I still don't think that any of those new functions justifies the need of a total compatibility breakdown, like the one that was artificially induced from python2.7 to python3. Python3 is good, but should have happened as a smooth transition from python2.7. The way it was handled was just a mess, and still keeps polluting the Python world. Next time somebody asks what Java has over Python... here it is: nothing like…
It was that one change that pushed python 3 from "some programs and libraries will need to be written" to "almost every single program and intro to python tutorial needs to change".
Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.
I haven't figured out the proper incantations to install matplotlib on python 3.x on OSX. So I stick with 2.7.
Earlier quoted context omitted.
> Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.
> The cognitive overhead of reading code is high enough without having to alias common operators. The cognitive overhead of reading code is, IME, often lower with context-approprate operator overloading (just as it is with well-chosen vs. poorly-chosen method names.) There is a reason human languages (and, yes, even the notation of mathematics) develops context-specific dialects, and it is to reduce the cognitive ove…