> How do you define just fine? Besides the total domination of the web programming space, which is of course aided by it being the only option: 1) Used by choice even on the server and application development (where it was never the only option, and wasn't even preferable/viable before) 2) Fast pace of language development 3) A thriving package ecosystem with millions of packages 4) Adopted by all major companies 5)…
And yet Python is eating the world: http://pypl.github.io/PYPL.html Not that I'm implying that 'popularity' is a good measure of anything.
Python itself won't be as much affected, what will affect you most are your dependencies. Imagine using a library and running in some kind of bug. You check newer version, looks like that bug was fixed, but the library now only works on python 3.6+. What will you do?
Backport the fix from 3.6, or just implement a fix yourself?
Yes, that's one option it will be feasible initially but it will get exponentially harder.
The simple reason is that there was no compelling feature to reward you for upgrading. You'd spend a tremendous amount of effort for dubious return and (until recently) a smaller ecosystem. 1. Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an in…
> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.…
Doesn't always blow up. Notably b"key" and "key" are now distinct dictionary keys, and both can coexist in the same dict. Is the absence of an optional key a fatal error? No, the program runs, and just does the wrong thing, or fails to copy the right value to the next stage, or whatever. Fun to debug.
> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.…
>Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up. We're talking about simple scripts, the solution is to not send in invalid characters.
even in very simple scripts you don't get invalid characters until you actually get them.
> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.…
Doesn't always blow up. Notably b"key" and "key" are now distinct dictionary keys, and both can coexist in the same dict. Is the absence of an optional key a fatal error? No, the program runs, and just does the wrong thing, or fails to copy the right value to the next stage, or whatever. Fun to debug.
To get b'key' and 'key' in a dictionary in python 3 you really need to try hard.
The only reasonable scenario I can think of is when you are porting python 2 code to python 3 and play with .decode() and .encode().
The simple reason is that there was no compelling feature to reward you for upgrading. You'd spend a tremendous amount of effort for dubious return and (until recently) a smaller ecosystem. 1. Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an in…
asyncio is actually really nice and with ThreadPoolExecutor / ProcessPoolExecutor it fit a lot of use cases I had hacked together things for in Python2. That alone was worth it to me.
This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.
Fair criticism. But shouldn't you be even more pissed that the Unicode release was botched and we're still talking about it more than 10 years after? When I upgrade to a new version of C# ... nothing happens. Backwards compatibility is what made Microsoft the company it is. I think Python deserves all the crap it gets for 2 vs 3.
They have to be backwards-compatible to persuade people to pay for their proprietary products rather than switch to another vendor.
In the academic data science-y world, the transition has passed the hump. In other words, where I was reluctant to switch a few years ago because some of my basic tooling was still in the 2 land, today the critical mass of important libraries has been ported and updated. Most of the cutting-edge docs and tutorials (Google's GPT2 for example) default to python3.