I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).
You can also use the .joinpath() method, in case you're not thrilled about divining the meaning of nonsense code like dividing a path by a string.
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…
Honestly, if they had just keep the print statement, the push back would have been almost non-existent. 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".
How hard would it have been to allow Python 2 and 3 code files to be mixed?
> Overloading operators for cute purposes is usually a misfeature Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. > There was a fad for this in the early C++ days. Yeah, like overloading the bitwise shift operators as stream insertion/extraction operators. > Python's classic overload problem comes from using "+" for concatenate.…
> 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.
On the other hand, someone might just as well say “the cognitive overhead of reading domain-specific code is high enough without having to alias common operators”, where “common operators” here means within the domain, in the numpy example matrix algebra.
How old is Python 3 now? I've always used Python for a "miscellaneous task" language, and still do... and even I find "...because you refuse to upgrade" a bit insulting. If I used it for something serious, even more so. The way 2.x -> 3.x was handled is/was/will is an absolute disaster. Upgrading simple scripts is a non-issue. Larger projects seem to always be a horrible pain.
There are a lot of people who refuse to upgrade. I have to use 2.7 at work for pretty much no reason at all, and I'm sure I'm not the only one.
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…
I'd like to respectfully disagree. I don't believe that there is a way to change how one of the fundamental types of a language works (string/unicode vs bytes/string) and make that a "smooth" transition. I know that is causes a lot of strain in the python community, but I applaud the core developers for doing that change, instead of getting stuck in the well-known "we have to support all legacy versions" hell.
> 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…
I'm pleased to see this perspective represented; it's the main reason I still really love the Perl programming language. The idea that context is useful and can actually help with clarity is a core concept.
Honestly, if they had just keep the print statement, the push back would have been almost non-existent. 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".
How hard would it have been to allow Python 2 and 3 code files to be mixed?
That’s a giant can of worms. One example problem: Python 2 has a type of class (old-style) that doesn’t exist in Python 3. What happens when you try to pass this type of class or one of its instances between the languages? There’s a bunch of stuff like that. You’d end up with a very weighed-down interpreter with a bunch of caveats if you ended up with one at all.
That's also a meaningless argument. It's true of any turing-complete language.
> "That's also a meaningless argument. It's true of any turing-complete language." Title 1 of course. Title 2 is a far more compelling reason to stay with Python 2.x. If I program for fun, then Python 3 is definitely worth playing around in, but for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact.
> for professional development, everything I do in Python is done in Python 2.x. That is not a theoretical argument, that is fact.
And everything I do professionally in Python is done in 3.x as of this January. Also fact! Industry standards sometimes move slowly, but they are moving.