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…
Why Is the Migration to Python 3 Taking So Long?
241–250 of 355 posts
Re: Why Is the Migration to Python 3 Taking So Long?
#242Earlier quoted context omitted.
> Python 2.6 and 2.7 supported Unicode just fine It did, but in a way that chainsaws support sculpting just fine. Technically possible. Very advanced people will know how to handle it. Everybody else is just going to injure themselves randomly. Most people writing py2 got the text/binary processing working on accident. Things appear to work until you throw actual Unicode into parameters and then nobody knows what hap…
Pictures of chainsaw sculptures for reference: https://www.google.com/search?q=chainsaw+sculptures&tbm=isch Some are quite good and finely detailed in my opinion. It's really nothing like what you'd expect after hearing chainsaw . There actually are small chainsaw, maybe even one-handed ones, to do that.
Re: Why Is the Migration to Python 3 Taking So Long?
#243Earlier quoted context omitted.
I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards…
I don't have a horse in the game and I'm not familiar with these people or the "fiasco" but your summary does not seem like accurate description of the issues raised in [5]. Here are the quotes that give me a very different take on the situation: The money was raised specifically to support development of requests 3 > [Reitz] announced that work had begun on "Requests 3", that its headline feature would be the native…
NO WHERE that I can see did Reitz say he would hire NJS to do some work. Is Reitz even setup properly to report for taxes or withold taxes on amounts paid to NJS, check paperwork for work eligiblity etc? Would this even be allowable if requests is not a business, or would deductions be disallowed as non business (ie, a payment to NJS -> subject to tax to both Reitz and NJS potentially?).
If you as a donor want full charitable compliance using PSF you would ask to give through them - and perhaps more would have been given if PSF had been an option.
I don't even see NJS on the requests contributor list:
https://github.com/psf/requests/blob/master/AUTHORS.rst
Finally, requests 3 has a number of features.
Re: Why Is the Migration to Python 3 Taking So Long?
#244How can we expect Python 3 to become the default if Python 2 still asserts such dominance?
Re: Why Is the Migration to Python 3 Taking So Long?
#245Earlier quoted context omitted.
I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards…
It's always amazing how adding a little money to the mix makes people lose their minds. NJS was working for free. KR raised some money from large businesses, then told NJS to keep working for free. NJS retroactively discovered that working for free is stupid, and tried demanding all the money NJS raised. This didn't happen, of course, since he had no leverage at all on NJS besides complaining online. The takeaway her…
And is it impossible that KR is doing an order of magnitude more work on the requests projects, with a much longer track records and raised the money directly to himself (and so has to pay taxes potentially on it) such that using it to support his work on requests is unreasonable?
Re: Why Is the Migration to Python 3 Taking So Long?
#246The 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…
Re: Why Is the Migration to Python 3 Taking So Long?
#247As somebody who only occasionally uses Python, the fact that the default `python` binary on my system resolves to Python 2.x and I need to specify `python3` to invoke 3.x, means I am quite often mistakenly using Python 2 instead of 3. How can we expect Python 3 to become the default if Python 2 still asserts such dominance?
In my archlinux installation, python resolves to 3, and I have to use python2 if I want 2
Re: Why Is the Migration to Python 3 Taking So Long?
#248Earlier quoted context omitted.
I don't have a horse in the game and I'm not familiar with these people or the "fiasco" but your summary does not seem like accurate description of the issues raised in [5]. Here are the quotes that give me a very different take on the situation: The money was raised specifically to support development of requests 3 > [Reitz] announced that work had begun on "Requests 3", that its headline feature would be the native…
The people who can and should complain if they feel misled about how their money was used are the people who donated the money. Have any of them complained? I say this with some seriousness. NO WHERE that I can see did Reitz say he would hire NJS to do some work. Is Reitz even setup properly to report for taxes or withold taxes on amounts paid to NJS, check paperwork for work eligiblity etc? Would this even be allowa…
Re: Why Is the Migration to Python 3 Taking So Long?
#249As somebody who only occasionally uses Python, the fact that the default `python` binary on my system resolves to Python 2.x and I need to specify `python3` to invoke 3.x, means I am quite often mistakenly using Python 2 instead of 3. How can we expect Python 3 to become the default if Python 2 still asserts such dominance?
That's not a python thing- that most likely has to do with your package manager. In my archlinux installation, python resolves to 3, and I have to use python2 if I want 2
Re: Why Is the Migration to Python 3 Taking So Long?
#250The 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.…
Not that I've seen.
Example of where Python 3 has rained shit on my parade: I wrote a program that backs up files for Linux. It works fine in python 2, but in python 3 you rapidly learn you must treat filenames as bytes otherwise your backup program blows up on valid Linux filenames. It's not just decoding errors, it's worse. Because Unicode doesn't have a unique encoding for each string, so the round trip (binary -> string -> binary) is not guaranteed to get you the same binary. If you make the mistake of using that route (which Python3 does by default) then one day Python3 will tell you can't open a file you os.listdir() microseconds ago and can clearly see is still there.
Later, you get some sort of error when handling one of those filenames, so you sys.stderr.write('%s: this file has an error' % (filename,)). That worked in python2 just fine, but in python3 generates crappy looking error messages even for good filenames. You can't try to decode the filename to a string because it might generate a coding error. This works: sys.write('b%b: this file has an error' % (filename,)), but then you find you've inserted other strings into error messages and soon the only "sane" thing to do is to to convert every string in your program to bytes. Other solutions like sys.write('%s: this file has an error' % (filename.decode(errors='ignore'),)) but corrupt the filename the user sees, are verbose, and worst of all if you forget it isn't caught by unit tests but still will cause your program to blow up in rare instances.
I realise that for people who live in a land of clearly delineated text and binary, such as the django user posting here, these issues never arise and the clear delineation between text and bytes is a bonus. But people who use python2 as a better bash scripting language than bash don't live in that world. For them python2 was a better scripting language than bash, but is being being depreciated in favour of python3 that's actually more fragile than bash for their use case. (That's a pretty impressive "accomplishment".) Perhaps they will go to back to Perl or something, because it stands Python3 isn't a good replacement.