Thank you very much for the news, it was useful to me
Sunsetting Python 2
651–660 of 733 posts
Re: Sunsetting Python 2
#652Maybe Python 2 can go away soon. Also, modern Python 3 support isn't even close to 100% either. https://pyreadiness.org/3.7/
That website is interesting, but maybe not as significant as it initially appears.
In some sense chardet doesn't explicitly support Python 3.7, but it's packaged for it in Debian Stable. I wouldn't expect any problems.
more-itertools is listed in white simply because it doesn't use any granular version classifiers on PyPi. It only has a python_requires setting, which is authoritative.
It's plausible that every single package on that page supports Python 3.7 in practice.
Re: Sunsetting Python 2
#653Earlier quoted context omitted.
> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferio…
> Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Updating software version is part of the job. Like creating tests, writing documentation, training newbies and dealing with customers. It's not hard just because we don't like to do it. Porting to Python 3 was not hard for most people. They just really, really didn't want to do it. I get it. I…
Like I said, it is not just about updating software. You can't realistically update all your dependencies by yourself.
You are stuck with a tough choice: Do I start out with Python3 and tons of broken packages? Do I limit myself to Python2 and face a costly migration later on? Do I run the extra cost of supporting both? This the choice you had face for the better part of ten years of migration. Perhaps it's not obvious that all Python-based software was worse for it, but that's what happened.
I'm not talking about some web backend service where most of what you do is trivial stuff. You can write and re-write that in almost anything, it doesn't matter.
Re: Sunsetting Python 2
#654Earlier quoted context omitted.
> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferio…
Which common parts of the science stack are still partially two-only? Conda ships on 3.7, and I'd consider it the definitive "scientific" stack.
You're right, most packages appear to be Python3 now. Nevertheless, a lot of client code has been written for the Python2 stack and it's still in widespread use. That stuff won't get migrated soon, if ever. Security doesn't really matter there anyway.
Re: Sunsetting Python 2
#655Earlier quoted context omitted.
You're missing the point. If decision makers saw it coming that Python will just break in two, they would have never allowed its use. Other "serious" programming languages rarely if ever break, and when they do, it's usually minor. Python2 will almost certainly still remain in widespread use and it will still get security updates through alternative distribution channels. It's not that much work fixing such relativel…
It's not "broken"... Python3 is just the evolution of the language. Languages change and evolve, some more and some less than others. Sure, Java or COBOL maybe have done a better job of not breaking backwards compatibility, but Python 3 isn't exactly Perl 6 here. But hey, if some 3rd party group effectively forks the language and maintains a Python2 branch after the official EOL date, good on them. But I'd argue that…
> It's not "broken"... Python3 is just the evolution of the language.
Python3 broke compatibility for spurious reasons. The language didn't change that much, it could have kept compatibility with minor concessions.
> Java or COBOL maybe have done a better job of not breaking backwards compatibility...
Literally every single other major language has done a better job at it. That's a big part of why they are major languages. Also, most of these are statically typed, so any minor breaking change is far less risky to pull off.
> ...but Python 3 isn't exactly Perl 6 here.
Well, maybe if Perl6 didn't happen Perl wouldn't be irrelevant today.
Re: Sunsetting Python 2
#656Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…
> (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...)
Isn't what code review and CI/CD is for?
Re: Sunsetting Python 2
#657Earlier quoted context omitted.
I think he means more 'craftsman' vs. 'builder' in mentioning professionals. I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using. And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often u…
Every "craftsman" I know is fanatical about the tools they . use, be they carpenters, chefs, artists, or programmers. Also, let's just call a craftsman what they are - experienced builders.
Ever seen anything built by a craftsman as opposed to a chippy :-)
At my first job we used to build some hydraulic models in hard wood that where works of art.
Our wood shop was so good they made a museum quality piece of furniture for our retiring boss and it was better than the best Chippendale furniture when new.
Re: Sunsetting Python 2
#658Earlier quoted context omitted.
Would PSF exponentially increasing support and maintenance costs for Python 2 into multimillion dollar contracts and bundling over-margined hardware in with the bundle to make it more of an IBM-like transition help?
Yep, someone has to pay in one way or another like Red Hat customers on 7, but to say Python has near the life cycle of COBOL is just disingenuous. Old COBOL still runs, but Python 2 programs will not. It really shows what the achievement languages like COBOL, RPG, and Fortran are in terms of longevity and migration.
You can still run 1960's code today for both COBOL and Fortran - I suspect some Fortan 2 oddities might not work I am thinking of the sense commands
Re: Sunsetting Python 2
#659Earlier quoted context omitted.
If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.
Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."
I can really understand that… but I believe that such organizations will experience significantly more problems than just Python upgrades. (I work for one.)
Re: Sunsetting Python 2
#660Earlier quoted context omitted.
Python 3's Unicode handling is uniquely bad. I haven't heard of any other language where you can obtain magic strings that crash the program if you try to print them: % python3.7 -c "import sys; print(sys.argv[1])" "$(echo -e '\xff')" Traceback (most recent call last): File " ", line 1, in UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed
Oh, that's a fun example. ("Fun", anyway.) The key surprising thing that's going on here is this clever hack (clever, but a hack): > In Python, file names, command line arguments, and environment variables are represented using the string type. On some systems, decoding these strings to and from bytes is necessary before passing them to the operating system. Python uses the file system encoding to perform this conver…
what an excellent writeup of why modern languages have something like 4 stringy types: bytes, unicode, os string, path string. you could go further if you want to talk to other computers.