One thing that confuses me about Python is just how many projects don't specify if the app is supposed to use 2 or 3, and the correct answer isn't 'either'. Check out something from Github, only to find I actually do need Python 2.7 or something. Is it that Python developers assume everyone will just intuit the version, or is there a default?
Sunsetting Python 2
261–270 of 733 posts
Re: Sunsetting Python 2
#262One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
More like Q) I like Python 2. Can I take over Python 2 maintenence? A) Sure. Just don't pretend to be us; call your fork something other than Python 2
If I can't make the executable, by default on installing, be 'python2', I'm adding quite a lot of pain to users (in particular, all those users with #!/usr/bin/env python2 in scripts).
Re: Sunsetting Python 2
#263Earlier quoted context omitted.
I wonder if they would have saved themselves five years of grief if they had done this five years ago.
Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2…
the RHEL vm's that I get at my job (enterprise IT) have python2 installed by default and no python3. It is much simpler to write scripts in python 2 (albeit written in a way to support forward compatibility with 3) because python2 is just there by default on every VM and its one less requisition order to write. We are actually upgrading to python 3 at the end of this month, but we lived with python 2 for a full year. Just want to make the point that "writing new py2 code now is just criminal" is a tad overzealous.
Re: Sunsetting Python 2
#264"What will happen if I do not upgrade by January 1st, 2020?" "You will lose chances to use good tools because they will only run on Python 3, you will slow down people who depend on you and work with you." The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right…
Totally agree, there's some degree of arrogance, especially in that section of the article. Maybe it's unintended, developers are not always good at PR.
> Totally agree, there's some degree of arrogance
Me too. Anyone who's running 15+ year old free software which came with 6 or possibly 12 years of notice to upgrade to the new version (depending on how you count it) and is complaining that it's no longer going to be supported for free by someone else, is being quite amazingly arrogant...
Maybe it's unintended, users of free software are not always good at being gracious.
Re: Sunsetting Python 2
#265Earlier quoted context omitted.
Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.
It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems dealing with unicode when you don't deal with unicode. You don't have a problem dealing with ranges and iterators when your most advanced looping construct is for(i = 0; i Portability issues in C are mostly between architectures, not standard versions. The fact tha…
However, I can also still run C++98 code happily, and there has been no suggestion (AFAIK) from any major C++ compiler to remove this support.
Re: Sunsetting Python 2
#266What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…
I'm not sure this is the right place, but maybe open an issue here?
Or email the mailing list for more help?
Re: Sunsetting Python 2
#267Python 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…
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done.
Good for you. Some of us had code bases of considerable size and complexity though.
The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit.
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it.
Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us.
I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.
Re: Sunsetting Python 2
#268Python 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…
One of the easiest compared to what? Certainly not a Python point release. A couple of points:
1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining.
(I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came out, I maintain that a) the transition was botched b) core dev did not listen to any of the problems people pointed out for _years_.)
To give you an idea of what botched means: several people, names withheld to protect the guilty, had to wade in 6 months worth of shit to get a 2.x release that made TLS vaguely OK, in, like, 2014?
Re: Sunsetting Python 2
#269When people mock me for writing long-term projects in Perl 5 ( https://github.com/jwr/ccheck ), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.
To be honest, never.
I work on a C program that's about 30 years old. We've slowly moved, at our own pace, to C99, then added some C++ here and there.
I don't ever want to have a forceful change, where I have to go and edit code which has worked correctly for over 15 years, just to make a compiler happy.
Re: Sunsetting Python 2
#270Python 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…
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…
Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.