Sunsetting Python 2(python.org)
python.org
Sunsetting Python 2
https://www.python.org/doc/sunset-python-2/
731 comments
By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy.
It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors.
The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !).
But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix.
The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about.
Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing.
Nonetheless, the screams from the first ones scared the later.
It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors.
The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !).
But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix.
The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about.
Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing.
Nonetheless, the screams from the first ones scared the later.
I think it's less about the difficulty of manual changes and more about the cost to verify that all of the changes actually work.
Dynamic typing on the language side, and a less than perfect test suite on the user side are not a good combination for large projects facing a project wide migration.
Dynamic typing on the language side, and a less than perfect test suite on the user side are not a good combination for large projects facing a project wide migration.
+1 to that. Add on top of it that by design, a lot of Python coders are not professional programmers, and you get yourself a better model of why migrating was so long. People coded an untested unstructured project that worked on their machine. It was enough to get the job done, and was a big reason they choose this language in the first place. But migrating that is not fun. Plus they didn't understand their own system, so touching it on such large scale seemed overwhelming, and hence the "it's too hard".
It's about risk. Python is a scripting language. That means that it's often auxiliary to a primary programming language. Your project might be in C++ but you use Python to package it or generate some assets, etc. Do you really care what language your auxiliary scripts are written in? No. Are you going to spend any amount of time converting them to Python 3 syntax? No. Your boss doesn't care, and you don't care. It would only end badly.
Scripting is only one use of python, it's also a math language that is used for implementing servers, machine learning and statistical analytics, data processing pipelines, and more. Numpy/Pandas allows fast math operations because it makes python the interface for operations implemented on c-arrays underneath the surface. For many many people, python is the primary programming language. The ability to use the same language for scripting as for your primary application is part of the charm of python.
The existence of the cloud means that you can scale wide instead of scaling tall, which makes developer time and complexity management more valuable than hardware efficiency. Python is optimized for primary applications in exactly that kind of environment, where the performance characteristics of something like C++ don't make up for the clumsiness of the language.
The existence of the cloud means that you can scale wide instead of scaling tall, which makes developer time and complexity management more valuable than hardware efficiency. Python is optimized for primary applications in exactly that kind of environment, where the performance characteristics of something like C++ don't make up for the clumsiness of the language.
> Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy.
In my very brief experience with python over the last few weeks this is very common. Half of our dependencies were abandoned before python 3 existed, when mercurial shuts off the hg we'll even lose the source to some of them. Python 3 get's the blame but the real problem is that the company has ignored maintenance for decades, it's entirely there own fault. There's no "business value" in maintenance until the whole lot needs to be rewritten.
Another underlying cause is package tools like pip, they make it too easy to take on dependencies with zero thought given to their maintenance windows and management think the can just ignore upgrading/replacing them regularly.
In my very brief experience with python over the last few weeks this is very common. Half of our dependencies were abandoned before python 3 existed, when mercurial shuts off the hg we'll even lose the source to some of them. Python 3 get's the blame but the real problem is that the company has ignored maintenance for decades, it's entirely there own fault. There's no "business value" in maintenance until the whole lot needs to be rewritten.
Another underlying cause is package tools like pip, they make it too easy to take on dependencies with zero thought given to their maintenance windows and management think the can just ignore upgrading/replacing them regularly.
> when mercurial shuts off the hg we'll even lose the source to some of them.
Are you perhaps thinking of when Atlassian removes the Mercurial repositories hosted on Bitbucket?
Mercurial isn't going anywhere or shutting down anything; it's open-source software with some very large users and committed developers.
(The majority of engineers at Facebook all work in one enormous Mercurial repo. Facebook naturally employs a few people to work full-time on Mercurial, and I don't think they're the only ones.)
Atlassian's decision about Bitbucket is regrettable. Especially regrettable is to actually delete repos for so many open-source projects that may not have active maintainers (rather than keep them online but read-only.) To my mind it marks a stain on their reputation that should make anyone think twice about relying on Atlassian for years to come.
But you should be able to avoid losing the source to any of your own dependencies. Between now and May 2020, go through all your dependencies and make sure you make your own clone of all the source repos.
Are you perhaps thinking of when Atlassian removes the Mercurial repositories hosted on Bitbucket?
Mercurial isn't going anywhere or shutting down anything; it's open-source software with some very large users and committed developers.
(The majority of engineers at Facebook all work in one enormous Mercurial repo. Facebook naturally employs a few people to work full-time on Mercurial, and I don't think they're the only ones.)
Atlassian's decision about Bitbucket is regrettable. Especially regrettable is to actually delete repos for so many open-source projects that may not have active maintainers (rather than keep them online but read-only.) To my mind it marks a stain on their reputation that should make anyone think twice about relying on Atlassian for years to come.
But you should be able to avoid losing the source to any of your own dependencies. Between now and May 2020, go through all your dependencies and make sure you make your own clone of all the source repos.
Yeah we have this particular problem, a Python program written in Python2 as late as 2014 for RHEL6, using Cython extensions. It compiles and packages fine for RHEL7, but when I run it on it just crashes upon receving a UDP packet from the network.
The original programmer is long gone, and I while I am a semi-competent Python scripter and a slightly above average C programmer, I'm not looking forward to having to dig deep into this code, and patch it up to keep running.
The original programmer is long gone, and I while I am a semi-competent Python scripter and a slightly above average C programmer, I'm not looking forward to having to dig deep into this code, and patch it up to keep running.
> By experience, people with large Python projects often overblown the difficulty of porting in their head. ... most projects get away with 2 weeks of investment.
Where did you come up with this "2 weeks" estimate? That has not at all been my experience.
Where did you come up with this "2 weeks" estimate? That has not at all been my experience.
What has been your experience?
> What has been your experience [converting Python 2 to 3]?
Many months.
Step zero is education. Your team has been programming in Python 2. You need to make sure they know the differences in the environments, how to use create cross-compatible code, and how to use six. They also need to setup a second dev enthronement, and become comfortable switching between 2 and 3 regularly.
Step 1/2 is prioritizing. Determine how important is the move to Python 3, and what other features and dev work will you have to sacrifice to make it happen. While having a nice plan in place may provide some level of comfort to management, you can be sure it will thrown out, amended, extended, and/or ignored throughout the project. Upgrading Python dev environments brings no near or mid term value to the company. So expect developers to continue their current work-load while also attending to this tech debt.
Step one is getting the libraries into shape. This is easy if your project only relies on actively developed libraries with good teams behind them, but nearly impossible for abandoned libraries with no new commits in the last few years. Sure in retrospect, it was a bad idea to use these libraries, but at the time, they were incredibly powerful or popular. Generally, for abandoned libraries, it's easier to find a newer Python 3 library than work on fixing someone else's code. But this may mean rewriting large parts of an app, and may alter functionality, so constant communication with product mangers and a flexible approach is necessary.
Second step is working on your own code. One or two modules is no problem. But more than a dozen takes time. Scripts like 2to3 are not helpful, you need to use tools like six and modernize.
Third step is testing. If you have a good team, then you should already have good tests with known coverage. In that case, you should make sure your coverage matches, and take a very hard look at the code that is not covered. If your tests cover less than say 60% of code, you need to invest quite a bit of time of either testing directly, or building many more tests.
Step 4 is partial rollout. There will inevitably be issues you didn't think about or catch, so you need to plan the roll-out carefully and either split traffic or at the very least be able to quickly revert.
Step 5 is to watch carefully for customer complaints. Any complaint may or may not be related to the switch from 2 to 3, and you need someone on your team who stays on top of that, and can communicate the issue to the correct module owner.
Step 6 is deciding when to drop support for Python 2 altogether, as there will have to be a time where you have the two environments running side-by-side while you're testing. After all of this work, you'd think this part would be easy, but in every organization some folks will be wary about dropping support for something that already works.
Obviously, this isn't just a linear progression, you can do some of these in parallel, and will likely have to take a step back a few times. My back-of-the napkin, experience based, non-scientific estimate suggests that a 100k LOC project can be managed by two developers in two-three weeks, but a 1M LOC project (including libraries) is roughly 5-8X that much work.
Many months.
Step zero is education. Your team has been programming in Python 2. You need to make sure they know the differences in the environments, how to use create cross-compatible code, and how to use six. They also need to setup a second dev enthronement, and become comfortable switching between 2 and 3 regularly.
Step 1/2 is prioritizing. Determine how important is the move to Python 3, and what other features and dev work will you have to sacrifice to make it happen. While having a nice plan in place may provide some level of comfort to management, you can be sure it will thrown out, amended, extended, and/or ignored throughout the project. Upgrading Python dev environments brings no near or mid term value to the company. So expect developers to continue their current work-load while also attending to this tech debt.
Step one is getting the libraries into shape. This is easy if your project only relies on actively developed libraries with good teams behind them, but nearly impossible for abandoned libraries with no new commits in the last few years. Sure in retrospect, it was a bad idea to use these libraries, but at the time, they were incredibly powerful or popular. Generally, for abandoned libraries, it's easier to find a newer Python 3 library than work on fixing someone else's code. But this may mean rewriting large parts of an app, and may alter functionality, so constant communication with product mangers and a flexible approach is necessary.
Second step is working on your own code. One or two modules is no problem. But more than a dozen takes time. Scripts like 2to3 are not helpful, you need to use tools like six and modernize.
Third step is testing. If you have a good team, then you should already have good tests with known coverage. In that case, you should make sure your coverage matches, and take a very hard look at the code that is not covered. If your tests cover less than say 60% of code, you need to invest quite a bit of time of either testing directly, or building many more tests.
Step 4 is partial rollout. There will inevitably be issues you didn't think about or catch, so you need to plan the roll-out carefully and either split traffic or at the very least be able to quickly revert.
Step 5 is to watch carefully for customer complaints. Any complaint may or may not be related to the switch from 2 to 3, and you need someone on your team who stays on top of that, and can communicate the issue to the correct module owner.
Step 6 is deciding when to drop support for Python 2 altogether, as there will have to be a time where you have the two environments running side-by-side while you're testing. After all of this work, you'd think this part would be easy, but in every organization some folks will be wary about dropping support for something that already works.
Obviously, this isn't just a linear progression, you can do some of these in parallel, and will likely have to take a step back a few times. My back-of-the napkin, experience based, non-scientific estimate suggests that a 100k LOC project can be managed by two developers in two-three weeks, but a 1M LOC project (including libraries) is roughly 5-8X that much work.
The entire science stack is "terrible C extensions". This is also the kind of tight-budgeted stuff that needs relatively rare Python/C developers, not just your average overpaid Python web developer.
I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.
I'm not saying we would've cured cancer if people didn't have to deal with this bullshit, but it's definitely a setback.
The science stack is also the one that starting migrating the earliest. Hell, numpy started supporting Python 3 eight years ago, while five years ago people were still complaining so much they got the EOL delayed. Not saying there are not some specific things that were late or never happened, but again, they are about a minority of projects. The thing is this minority is making all the noise.
Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered. Again, it's important to remember you can't make everybody happy, especially if your job is important. If porting is easy for 90% of projects, you did a great work, period. 10% of millions of users having it hard is still going to raise a lot of voices against you by the sheer power of numbers, but you did ok.
There is also dishonesty. Most people reporting this problem or that problem didn't actually encounter it. They are reporting somebody else experience they heard about because they wanted to make a point. Or vaguely tried something and ran away after they saw 10 minutes of fiddling didn't solve it.
In 10 years going from company to company, I met only 2 projects that were hard to port, but much, much more complainers. When I looked at what was really going on, the fact was just that they were afraid to port, and so just repeated all the stuff other people told them would go wrong. Or they tried running a few scripts for 5 minutes on Python 3 and gave up seeing too many error messages.
I know there are honest situations in the lot. But again, the most honest people are not making noise, because they just ported their code and noticed it wasn't the hardship they've been told.
Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered. Again, it's important to remember you can't make everybody happy, especially if your job is important. If porting is easy for 90% of projects, you did a great work, period. 10% of millions of users having it hard is still going to raise a lot of voices against you by the sheer power of numbers, but you did ok.
There is also dishonesty. Most people reporting this problem or that problem didn't actually encounter it. They are reporting somebody else experience they heard about because they wanted to make a point. Or vaguely tried something and ran away after they saw 10 minutes of fiddling didn't solve it.
In 10 years going from company to company, I met only 2 projects that were hard to port, but much, much more complainers. When I looked at what was really going on, the fact was just that they were afraid to port, and so just repeated all the stuff other people told them would go wrong. Or they tried running a few scripts for 5 minutes on Python 3 and gave up seeing too many error messages.
I know there are honest situations in the lot. But again, the most honest people are not making noise, because they just ported their code and noticed it wasn't the hardship they've been told.
[deleted]
> 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 inferior version of Python, whether it was because library choice was limited (Python3) or because the language was intentionally left without feature backports (Python2). There was a huge amount of plain "brokenness" in the ecosystem and it was a huge waste of everyone's time.
...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 inferior version of Python, whether it was because library choice was limited (Python3) or because the language was intentionally left without feature backports (Python2). There was a huge amount of plain "brokenness" in the ecosystem and it was a huge waste of everyone's time.
> 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 didn't want to add that on my plate too. Like I didn't want to migrate from my Centos 7, I didn't want to move from mysql to postgres and I didn't want to learn the entire setup of Webpack. 3 times. But "suffering" is a big word that has no place for the vast majority of projects.
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 didn't want to add that on my plate too. Like I didn't want to migrate from my Centos 7, I didn't want to move from mysql to postgres and I didn't want to learn the entire setup of Webpack. 3 times. But "suffering" is a big word that has no place for the vast majority of projects.
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.
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.
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.
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.
djjanancnic(1)
> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands.
This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often.
> Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips.
D'accord. Exactly. I had very fruitful discussions with professional builders about tools, tool brands and their respective strengths and weaknesses - but never has a professional decried Bosch Pro vs Makita vs DeWalt. One has ones favorites - and that is fine. But badmouthing - I have never encountered.
This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often.
> Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips.
D'accord. Exactly. I had very fruitful discussions with professional builders about tools, tool brands and their respective strengths and weaknesses - but never has a professional decried Bosch Pro vs Makita vs DeWalt. One has ones favorites - and that is fine. But badmouthing - I have never encountered.
You've never encountered badmouthing from a pro builder about other tool brands? How many did you talk to? Builders make the Ford v Chevy debates look minimal in comparison.
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 uses pneumatic tools for this).
I'm sure he prefers a certain brand, but unlike popular YouTube personalities and more 'celebrity' builders, he isn't a brand ambassador for Craftsman, DeWalt, Milwaukee, Ryobi, etc.
But yeah, when you talk about 'builders' (the more common carpenters you encounter on most job sites), it seems like most of them will die on a sword defending whatever brand(s) they've sunk a fortune into.
I'm a DeWalt guy, mostly because I invested in a 20V Max drill a long time ago and have a ton of batteries for all my electric tools now. But I used to use Makita before switching systems. I wouldn't call myself a master carpenter by any means, but like AvE, I find good and bad in almost all the 'top tier' lines from tool manufacturers.
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 uses pneumatic tools for this).
I'm sure he prefers a certain brand, but unlike popular YouTube personalities and more 'celebrity' builders, he isn't a brand ambassador for Craftsman, DeWalt, Milwaukee, Ryobi, etc.
But yeah, when you talk about 'builders' (the more common carpenters you encounter on most job sites), it seems like most of them will die on a sword defending whatever brand(s) they've sunk a fortune into.
I'm a DeWalt guy, mostly because I invested in a 20V Max drill a long time ago and have a ton of batteries for all my electric tools now. But I used to use Makita before switching systems. I wouldn't call myself a master carpenter by any means, but like AvE, I find good and bad in almost all the 'top tier' lines from tool manufacturers.
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.
Weird. I'd say the attitude exhibited by De Niro's character Sam in Ronin is more common. They're just tools.
You want it written in C for a 16bit bargain basement ALU? I can do that. You want two implementations, one in Pascal and the other in PHP? Not a problem. You want my advice? No? That's fine too, the advice is expensive and who knows after all these years if it's even worth anything.
You want it written in C for a 16bit bargain basement ALU? I can do that. You want two implementations, one in Pascal and the other in PHP? Not a problem. You want my advice? No? That's fine too, the advice is expensive and who knows after all these years if it's even worth anything.
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.
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.
Having used quite a few different brands over years,I'd say that most of the more expensive ones are just good enough.All the nitty gritty details why Makita does a better job than HILTI or that Milwaukee will last forever are mainly personal experiences.
With most categories of gear, there's a sharp quality threshold that hits below a given price range, and once you are above it, you need not go further to do professionally useful work. It's been a helpful rule of thumb for me.
Personally, I'm biased towards Milwaukee's RED Fuel cordless stuff, because I used a cordless hammer drill of theirs at work and it lasted hours, which signaled to me that if something like a hammer drill going through 1-1/2 foot concrete continuously can last a long time, then a normal drill or an impact driver probably won't die on me while working.
I do like the grips and ergonomics of some brands more than others.
I do like the grips and ergonomics of some brands more than others.
I used to work for a plumbing company,which was divided into two divisions: mechanical ( heavy pipework, industrial heating and any other big stuff) and the rest(household heating, general plumbing,etc.) The mechanical division swore by Milwaukee.They had it all. The rest of us had anything from Makita to Hitachi. Still, something thst got stuck in my memory: a colleague was using high end Hilti power drill to drill holes in ceiling.He did hundreds of holes a day.The drill, despite its superior design kept failing because of concrete dust falling into the drill.Hilti failed to address this when asked how to deal with this,so the guy ended up putting a plastic pipe cover on his drill to protect its internals from getting all the dust.. Worked pretty well.
No, never. I need to invest in power tools myself so I’ve been asking a bunch of coworkers who use their personal power tools at work. The response I hear from everybody, without fail, is “Well, there are a lot of good brands.” I don’t even hear people defending their own choices.
The one piece of concrete advice I got was “Whatever brand you get, go for the 20V, not the 12V”. Last week I saw that same guy at work showing off his 12V driver. So I’m pretty sure nothing matters, and I’ll probably just get the brand with the prettiest color.
The one piece of concrete advice I got was “Whatever brand you get, go for the 20V, not the 12V”. Last week I saw that same guy at work showing off his 12V driver. So I’m pretty sure nothing matters, and I’ll probably just get the brand with the prettiest color.
[deleted]
[deleted]
Well it’s a shitty analogy because a swap to torx is basically a single API change.
The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it.
“Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it.
“Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
Most non-tech businesses have no budget for that kind of tech debt work.
That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.
That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.
Using python2 is in no way similar to going without fire insurance. There are internal-only apps that will run fine for decades to come with no risk to the business on py27.
There are many maintenance mode projects where the switch to 3 represents absolutely no upside and is all downside risk. Not everyone is developing web apps in constant flux that are exposed to the Internet. That is a tiny fraction of python’s use cases.
There are many maintenance mode projects where the switch to 3 represents absolutely no upside and is all downside risk. Not everyone is developing web apps in constant flux that are exposed to the Internet. That is a tiny fraction of python’s use cases.
> I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make.
A security system and fire insurance is at most around $2000/month, and it's a cost that is understood and often required by law. Diverting a $100k+/year employees to spend their time on tech debt is quite a bit more expensive.
Companies rightly try to minimize time devoted to tech debt.
A security system and fire insurance is at most around $2000/month, and it's a cost that is understood and often required by law. Diverting a $100k+/year employees to spend their time on tech debt is quite a bit more expensive.
Companies rightly try to minimize time devoted to tech debt.
Actually most of them do money, however in these type of companies tech people aren't listed to as much,as maybe sales or finance are. It just depends on who's running the circus on the day: if it's a guy with short term goals only- you'll never get a budget,but the ones with longer visios would most likely listen.
There's not budgeting for fire insurance or security systems, and then there's deliberately building your workplace next door to an asylum for pyromaniacs and across the street from a gas station.
If you built software using Python 2 at any point in the past 5 years, you have no right to complain about the added technical debt of updating to Python 3. But not wanting to incur that technical debt in the first place would also have been a good reason not to use Python 2 in the first place; whether that means adopting Python 3 early or simply using a completely different language.
If you built software using Python 2 at any point in the past 5 years, you have no right to complain about the added technical debt of updating to Python 3. But not wanting to incur that technical debt in the first place would also have been a good reason not to use Python 2 in the first place; whether that means adopting Python 3 early or simply using a completely different language.
"Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line."
Congratulations. You're fired.
Congratulations. You're fired.
"Hey Joe, why did our customer database get leaked and published on a dark-net site?"
"Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt."
"Congratulations, you're fired."
Same outcome either way... might as well make some effort to do the right thing along the way...
"Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt."
"Congratulations, you're fired."
Same outcome either way... might as well make some effort to do the right thing along the way...
You’re confusing runtimes with the language. Py27 as a language has no security flaws that would allow a database to get leaked.
People will continue to use py27 going forward with likely a pay-for-support runtime because that’s cheaper and less risky than changing a million lines of python code.
People will continue to use py27 going forward with likely a pay-for-support runtime because that’s cheaper and less risky than changing a million lines of python code.
I would assume it’s the dependent libraries in your 27 project that no longer get support, not the language itself.
Nah, you're not fired. That's why you CYA and get it in writing. It's the manager who decided that they didn't want to do a rewrite, it's not your problem they didn't listen to your advice.
Like it or not, there are a lot of teams that choose to incur technical debt to avoid what is seen as needless work on something that is working fine at the moment.
Like it or not, there are a lot of teams that choose to incur technical debt to avoid what is seen as needless work on something that is working fine at the moment.
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 relatively rare issues versus migrating a major codebase.
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 relatively rare issues versus migrating a major codebase.
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 using that is risky in the same way that using a Pale Moon or Waterfox is (arguably) riskier than using mainstream Firefox.
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 using that is risky in the same way that using a Pale Moon or Waterfox is (arguably) riskier than using mainstream Firefox.
> Python 3 isn't exactly Perl 6 here.
For what it’s worth, Perl 6 can load Perl 5 libraries: https://github.com/niner/Inline-Perl5
For what it’s worth, Perl 6 can load Perl 5 libraries: https://github.com/niner/Inline-Perl5
> 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.
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.
> Literally every single other major language has done a better job at it.
C++'s upgrade woes make Python 3 look downright trivial in comparison.
C++'s upgrade woes make Python 3 look downright trivial in comparison.
What are you talking about? C++ has had very few breaking changes in the language.
If you're talking about ABI breaking, that's a different story. Python breaks the ABI in every major release as well. That generally requires a recompile, not a major code migration.
If you're talking about ABI breaking, that's a different story. Python breaks the ABI in every major release as well. That generally requires a recompile, not a major code migration.
IceWeasel FTW.
Security through obscurity, baby...
Security through obscurity, baby...
> “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.
Every non-tech business that maintains technical infrastructure finds itself doing that kind of tech-debt work regularly (if, often, chronically behind the vendors recommended schedule) for every platform they use Py2 to Py3 may (or may not, really) have been a bit more painful than a (multistep, because those types of shops never do it timely enough that a single-version-bump makes sense) .NET framework, Visual Studio, SQL Server, and Windows Server upgrade (and, yeah, those often happen together as multistep upgrades in slow enterprise shops), but it's not a fundamentally different kind of problem (and replacing dependencies that didn't make the same upgrade, often because they were abandoned years before the firm made it's upgrades, is often a part of that.)
Every non-tech business that maintains technical infrastructure finds itself doing that kind of tech-debt work regularly (if, often, chronically behind the vendors recommended schedule) for every platform they use Py2 to Py3 may (or may not, really) have been a bit more painful than a (multistep, because those types of shops never do it timely enough that a single-version-bump makes sense) .NET framework, Visual Studio, SQL Server, and Windows Server upgrade (and, yeah, those often happen together as multistep upgrades in slow enterprise shops), but it's not a fundamentally different kind of problem (and replacing dependencies that didn't make the same upgrade, often because they were abandoned years before the firm made it's upgrades, is often a part of that.)
> Most non-tech businesses have no budget for that kind of tech debt work.
The thing about debt is that ignoring it doesn't make it go away magically. If business relies on tech for crucial functions, it's only a matter of time before debt comes due.
The thing about debt is that ignoring it doesn't make it go away magically. If business relies on tech for crucial functions, it's only a matter of time before debt comes due.
>>”Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work
If you don’t push your clients/employer to have room in their budgets for these types of things, you are the one being naive.
If you don’t push your clients/employer to have room in their budgets for these types of things, you are the one being naive.
[deleted]
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?
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?
> 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
IIRC the messaging from Guido and Python core dev circa PyCon 2008 and 2009 was that it was good enough for people to start thinking about how they might migrate. This resulted in experiments with different approaches to migrations, maintenance of versions for Python 2 and 3, etc, but at that time there wasn't a clear end date and no rush to migrate. It seems like a lot of people misinterpreted what was actually said. Similar misinterpretations seem to happen within the wider internet community around the GIL and perf considerations. That cliff is finally here ten years later after a lot of experience with migrations.
IIRC the messaging from Guido and Python core dev circa PyCon 2008 and 2009 was that it was good enough for people to start thinking about how they might migrate. This resulted in experiments with different approaches to migrations, maintenance of versions for Python 2 and 3, etc, but at that time there wasn't a clear end date and no rush to migrate. It seems like a lot of people misinterpreted what was actually said. Similar misinterpretations seem to happen within the wider internet community around the GIL and perf considerations. That cliff is finally here ten years later after a lot of experience with migrations.
Python 3.1 came out 10 years ago. 3.2 was released in 2011. What does that mean about the complaints since, let’s just say 2015 to be fair?
I heard several people saying that 3.6 was the first Py3 worth transitioning to. Largely for async (I think async/await came to live then). There is this take on performance: https://hackernoon.com/which-is-the-fastest-version-of-pytho...
For me, having run a slew of large Python code bases, 3.3 was the first 'useful' version to upgrade to as it re-enabled u"string" syntax. Without that, making 2/3 compatible code was hard.
3.5 fixed % formatting for bytes, further making 2/3 transitions easier (or harder, depending on your use/abuse of strings vs bytes).
3.6 added the first 'exciting' new feature: f"formatted string {literals}" if you don't have an asynchronous type project that can make good use of async/await.
3.5 fixed % formatting for bytes, further making 2/3 transitions easier (or harder, depending on your use/abuse of strings vs bytes).
3.6 added the first 'exciting' new feature: f"formatted string {literals}" if you don't have an asynchronous type project that can make good use of async/await.
I do think "worth transitioning" is the final group of people who have the most reason to hold off. If new features are what made it worth transitioning, then it probably was 3.6 with async/await. If you relied a lot of unicode and already had a mature codebase, you'd wait too. If it was a new project you'd probably start with 3 much earlier because of unicode.
Ordered dicts and f-strings are also very sweet!
I expect sametmax was referring to the new feature in Python 3.6 that plain old `dict` now preserves the insertion order of its elements. See docs here:
https://docs.python.org/3/library/stdtypes.html#dict.values
(Or in language-lawyer terms: CPython 3.6 introduced this behavior and documented it as an implementation detail, and for Python 3.7+ it's guaranteed a feature of the language proper.)
(Or in language-lawyer terms: CPython 3.6 introduced this behavior and documented it as an implementation detail, and for Python 3.7+ it's guaranteed a feature of the language proper.)
And optional type specifiers. This was the key for me.
The Py3 string handling was beyond frustrating prior to 3.6. For what I do, Unicode complexity is not required. Having to stuff it into everything was more trouble than it was worth.
The ubiquity of emoji alone mean that Unicode is everyone's problem in 2010+, and ignoring it won't make it go away. It's Python 2.x where dealing with Unicode (which is everywhere) is far too complex, and more trouble than it is worth. The "complexity" of Python 3 string handling is worth it, and no worse (even < 3.6) than any other modern programming language, and possibly easier than some by making clear runtime errors where accidents are easiest to make. (Though arguably, perhaps I'm biased by having done plenty of Unicode work in other languages that Python 3 did seem so familiar and easy from the start for my Unicode needs. Your mileage of course varies, we all have different backgrounds.)
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 "<string>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowedOh, 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 conversion ... > > On some systems, conversion using the file system encoding may fail. In this case, Python uses the surrogateescape encoding error handler, which means that undecodable bytes are replaced by a Unicode character U+DCxx on decoding, and these are again translated to the original byte on encoding.
https://docs.python.org/3/library/os.html#file-names-command...
This is meant as a way of fudging the fact that (a) for UI purposes, you want to treat filenames as text strings; (b) your Linux filenames are probably all encoded as UTF-8 (or your locale encoding); (c) but they might not be -- they could be arbitrary bytes, except only NUL; (d) and if they are, you really want to not munge the name when you go back and try to operate on the file.
The fudge is that filenames get decoded as (by default) UTF-8... but if invalid, the offending bytes get stuffed into the UTF-16 surrogate space. Then filesystem APIs encode as UTF-8, except they look for that surrogate hack and turn those to the original bytes, so it all round-trips.
It goes pretty wrong if you try to hand such a hacked-up string to something that just expects to encode normal real Unicode with UTF-8, though. That's what's happening in your example.
The magic words are `os.fsdecode` -- that's how you get back bytes round-trip clean from that hack.
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 conversion ... > > On some systems, conversion using the file system encoding may fail. In this case, Python uses the surrogateescape encoding error handler, which means that undecodable bytes are replaced by a Unicode character U+DCxx on decoding, and these are again translated to the original byte on encoding.
https://docs.python.org/3/library/os.html#file-names-command...
This is meant as a way of fudging the fact that (a) for UI purposes, you want to treat filenames as text strings; (b) your Linux filenames are probably all encoded as UTF-8 (or your locale encoding); (c) but they might not be -- they could be arbitrary bytes, except only NUL; (d) and if they are, you really want to not munge the name when you go back and try to operate on the file.
The fudge is that filenames get decoded as (by default) UTF-8... but if invalid, the offending bytes get stuffed into the UTF-16 surrogate space. Then filesystem APIs encode as UTF-8, except they look for that surrogate hack and turn those to the original bytes, so it all round-trips.
It goes pretty wrong if you try to hand such a hacked-up string to something that just expects to encode normal real Unicode with UTF-8, though. That's what's happening in your example.
The magic words are `os.fsdecode` -- that's how you get back bytes round-trip clean from that hack.
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.
That seems more like a difference of opinion on how to handle a bad string than an example of python 3 being bad. I'd argue failing silently is worse, as in programs outside of your toy example you might end up storing badly encoded data etc. Broken data is way worse to deal with than a crashing app
Nothing I do in my ordinary routine full-time engineering work for the past decade has required or does require anything outside the ASCII character set or, alternatively, plain bytes. The use cases my users present to me does not include emoji or non-ASCII characters. If those arise, naturally, one would select tools to address those needs. I don't know the future. In a year or two, my routine work may, of course, change.
> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1?
> core dev did not listen to any of the problems people pointed out for _years_
What problems were those?
I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1?
> core dev did not listen to any of the problems people pointed out for _years_
What problems were those?
A major, breaking issue[1] was how Python 3 handled missing LC_* variables. By default, a Python script would simply crash with any non-ASCII input or output. It was fixed[2] in 3.5[3].
[1]: https://bugs.python.org/issue19977
[2]: https://www.python.org/dev/peps/pep-0540/
[3]: https://docs.python.org/release/3.5.0/whatsnew/3.5.html
[1]: https://bugs.python.org/issue19977
[2]: https://www.python.org/dev/peps/pep-0540/
[3]: https://docs.python.org/release/3.5.0/whatsnew/3.5.html
There were very few new features, only breaking changes. With the exception of Unicode defaults which few yet understood.
Strings in python3 were terrible for memory well into mid-3. Raymond Hettinger is a core dev and he recently stated on Twitter that he didn’t feel py3 was a clear upgrade win until this most current release.
Raymond has been consistent in saying Python 3.6.1 was the release where Python 3 became better than Python 2. That was March 21, 2017, and we're now in Python 3.7.4.
I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release".
Also to understand why it took so long is because Python 2 kept improving after Python 3s release. Python 2.7 was a great release and many further features from Python 3 got backported in it's 2.7.x point release.
I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release".
Also to understand why it took so long is because Python 2 kept improving after Python 3s release. Python 2.7 was a great release and many further features from Python 3 got backported in it's 2.7.x point release.
Sorry, I misremembered. 3.8 is the first one he said is a clear winner: https://twitter.com/raymondh/status/1167218640095043586
2017 is a lot more recent than 2008 (Py 3.0).
> 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
The post you're responding to starts verbatim with `Python 2 to 3 (at least by 3.3 or so)` and your reply is about Python 3.1, released 3 years earlier. The amount of changes was quite big.
The post you're responding to starts verbatim with `Python 2 to 3 (at least by 3.3 or so)` and your reply is about Python 3.1, released 3 years earlier. The amount of changes was quite big.
You've got to let go of these grudges. Time has past, enough time that you shouldn't be complaining about these things here, because all you're doing is giving the Python 2 "out of my cold dead hands" crew more ammo.
Just let it go...
Just let it go...
> 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.
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.
I found some Unicode bugs in porting—and I get continued free security updates. Seems fair to me, and certainly not “no benefit”. I can keep on 2.7 as long as I like; nobody’s forcing me to port. Compare the situation with Java!
I like Python. But it loses in the upgrade comparison to Java. Existing Java code almost always just keeps working with new compilers and JVMs. And new JVMs tend to increase performance of your code for relatively little upgrade effort.
In my uninformed opinion not including a python 2 interpreter in python 3 was the first mistake
> Compare the situation with Java!
Isn’t that comparable to java? Oracle gives you paid security updates on version 8. You can keep using the previous version without security updates or migrate to OpenJDK 8, which have their own security group. More options, seems better to me.
Isn’t that comparable to java? Oracle gives you paid security updates on version 8. You can keep using the previous version without security updates or migrate to OpenJDK 8, which have their own security group. More options, seems better to me.
Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.
Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
>considering timelines in engineering are to support a version for 60 years.
In the vast minority of cases.
Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running?
Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I certainly can't expect support for my car for longer than 25 years.
In the vast minority of cases.
Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running?
Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I certainly can't expect support for my car for longer than 25 years.
If there's a difference it's not time scale necessarily, it's that CPAs are better at amortizing support/maintenance costs across decades. CPAs have amazingly detailed depreciation charts for non-software engineering lifecycles. If you build a civil engineering project, you figure out asset depreciation versus maintenance schedules, and you budget accordingly.
I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).
I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).
They really need our help :-)
In a previous job that was mostly in an engineering/manufacturing department, but with a lot of Perl/Python automation scripts, we had an internal conference. One of the keynote talks was when not to automate using SW. It went into the cost of maintaining SW over the long term - including the fact that authors leave, and people who understand their scripts require higher salaries. Most people who write these scripts are not hired for SW roles, so their replacements likely cannot debug/extend.
In a previous job that was mostly in an engineering/manufacturing department, but with a lot of Perl/Python automation scripts, we had an internal conference. One of the keynote talks was when not to automate using SW. It went into the cost of maintaining SW over the long term - including the fact that authors leave, and people who understand their scripts require higher salaries. Most people who write these scripts are not hired for SW roles, so their replacements likely cannot debug/extend.
Classic cars can still get parts after 25 years, but a lot of times its custom machine shop stuff. There is a market for it. Really there's also a market for restoring old computers (look at The 8-Bit Guy, LGR, The Living Computer Museum (Seattle) and all those other people who restore old hardware for fun and education.
But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.
But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.
[deleted]
You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.
You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.
The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.
> IBM
> PSF
These are two very different kinds of institutions!
People who need COBOL support from IBM are paying a lot of money. Giant piles of money can get you many kinds of help that people won't volunteer to do for free... among them, maintaining ancient software in amber.
If you need Python 2 support and you are willing (and able) to pay the kind of money that IBM's customers pay for COBOL support, you'll be OK. For a start, Red Hat (aka also IBM!) shipped Python 2 in RHEL 8, which means they'll be supporting it until 2029 at the earliest.
> PSF
These are two very different kinds of institutions!
People who need COBOL support from IBM are paying a lot of money. Giant piles of money can get you many kinds of help that people won't volunteer to do for free... among them, maintaining ancient software in amber.
If you need Python 2 support and you are willing (and able) to pay the kind of money that IBM's customers pay for COBOL support, you'll be OK. For a start, Red Hat (aka also IBM!) shipped Python 2 in RHEL 8, which means they'll be supporting it until 2029 at the earliest.
To circle back to the original point, no COBOL committee would break commonly running COBOL programs like the Python 2-3 transition. Using COBOL in an example with Python is just wrong. Maybe the break is justified, maybe it isn't, but some languages do a lot of work to make sure things continue to work.
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.
> but Python 2 programs will not
Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work, you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.
Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work, you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.
Any software in the modern era that isn't upgraded for new OSes or security patched is dead.
Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.
They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.
What free things are supported for 60 years in engineering applications?
Name one.
Name one.
Fairly ancient Fortran compiles OK in open source compilers. Not quite 60 years old, yet, but it'll be there soon.
It's already >65 years old. The 65th birthday was this summer 2019.
We sell welding systems to weld stainless steal, copper pipes, etc. We always give a warranty of 24 month, guarantee paid support for 10 years, and support older machines only if possible. I am not sure which industry you are talking about, but 60 years is the exception in my experience.
I think this is where paid support comes into picture. Volenteers can keep improving Python, business that cant/wont upgrade can pay someone to "handle it", and consultants can make money. Everyone is happy.
The FAQ does point to vendors that plan to offer long time support/conversion paid support plans.
You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot.
If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities.
It's not just about Py2/3. Dependency rot is one of the worst form of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.
If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities.
It's not just about Py2/3. Dependency rot is one of the worst form of technical debt. It often shows broken CI, broken security scanning, lots of generally broken processes that will just keep hurting a team further and further down the line.
I don't really agree with much of what the person you replied to said, but certain domains have had their hands tied and I also can't imagine them working as you describe.
CG/Visual Effects industry is still firmly using Python 2. Only in 2020 are they taking the first step to transition to Py3 [1]. Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya as well as libraries and APIs. None of them have released a version that runs Python 3 yet.
The reasons for delaying it (mentioned in a footnote on that page) makes sense to me. Previous years were focusing on coordinating updates to GCC, Boost, C++14, Qt, and waiting on Python bindings for Qt.
Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness. Requirements change for each project and previous requirements are often sacrificed (until a new project needs them in a few years).
I'm itching to move to Python3, but even for standalone tools I've felt it better to choose a completely different language (or Python2) instead trying to mix Python2 and 3 because having them co-exist creates more headaches in managing the environments, dependencies, and coding styles.
[1] https://vfxplatform.com
CG/Visual Effects industry is still firmly using Python 2. Only in 2020 are they taking the first step to transition to Py3 [1]. Users and studios are held back because the Python runtime is used inside major applications; Nuke, Houdini, Maya as well as libraries and APIs. None of them have released a version that runs Python 3 yet.
The reasons for delaying it (mentioned in a footnote on that page) makes sense to me. Previous years were focusing on coordinating updates to GCC, Boost, C++14, Qt, and waiting on Python bindings for Qt.
Also, I've worked at a couple studios many people have probably heard of and none of them have unit tests covering much of their code. The focus is on tools that facilitate in-house artists where responsiveness to needs are valued over architecture and completeness. Requirements change for each project and previous requirements are often sacrificed (until a new project needs them in a few years).
I'm itching to move to Python3, but even for standalone tools I've felt it better to choose a completely different language (or Python2) instead trying to mix Python2 and 3 because having them co-exist creates more headaches in managing the environments, dependencies, and coding styles.
[1] https://vfxplatform.com
> If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities.
I am not sure how you could possibly know this. You have no idea what else they were working on instead.
I am not sure how you could possibly know this. You have no idea what else they were working on instead.
Because no matter what you're working on, you won't get very far without eating, sleeping and at least once a decade putting in some maintenance work.
My overriding motto as an engineer is "If it ain't broke, don't fix it." My python 2.7 component has run flawlessly for years now, with virtually no need to update. I just haven't had to worry about it. We decided to update to py3 a few weeks ago, and this component is now having sporadic hiccups. Like, it runs fine 95% of the day, then all of a sudden a timer callback in a Tornado ioloop just stops running for 30 seconds after working fine for 10 hours or something. This disables the entire trading system. It's hard to explain to anyone, myself included, what I gained by updating a perfectly working system to something that now shuts production a few times a day. Now my time is diverted from doing actually useful tasks to fixing code that wasn't broken to begin with.
The tone of your writing is rude, unpersuasive, and lowers the level of discourse on the forum.
That’s like, your opinion, man.
I didn’t think it was the most amazing comment either, however, it was intended more to illustrate how things are rather than how they ought to be, I think some interpreted as a strong opinion in favor of the circumstances which was not intended. Based on how it scored (somewhat surprisingly) it clearly resonated with more than a few.
I didn’t think it was the most amazing comment either, however, it was intended more to illustrate how things are rather than how they ought to be, I think some interpreted as a strong opinion in favor of the circumstances which was not intended. Based on how it scored (somewhat surprisingly) it clearly resonated with more than a few.
You've managed to say their analogy is bad in two paragraphs without even explaining why it's a bad analogy. You even admit you don't really understand what they were trying to say. Poor explanation, or poor understanding?
If an analogy requires more explanation than the original concept what purpose does it serve?
I think in this case at best the analogy grossly oversimplifies the issue. If it really were just a “screwdrivers” problem as explained then the 2 to 3 migration would have been mostly trouble free and would have happened. Clearly it did not go that way so that analogy can not possibly be appropriate.
I think in this case at best the analogy grossly oversimplifies the issue. If it really were just a “screwdrivers” problem as explained then the 2 to 3 migration would have been mostly trouble free and would have happened. Clearly it did not go that way so that analogy can not possibly be appropriate.
[not speaking on behalf of any employer, opinions my own]
I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate.
The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but:
1. Even a well-tested project won't have tests that cover 100% of code paths and behavior.
2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration.
I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.
I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate.
The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but:
1. Even a well-tested project won't have tests that cover 100% of code paths and behavior.
2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration.
I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.
> The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely.
Compiler errors sure would be handy here :^)
Compiler errors sure would be handy here :^)
Those are probably the biggest missing piece. Compilers and static analysis tools make it possible for relatively small teams to migrate between compiler versions for C++, Java, etc. It's often still a huge amount of work, but it allows a lot of the work to be automated, and doesn't require an engineer to manually inspect every module.
As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users.
Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indeed, python is not the language for your use-case (which is fine btw!). Java never made breaking changes, but it forced a massive limitation in the design-space for some language features (generics for example) for which it still pays a heavy price years later.
Also I think you're too harsh on the analogy, most of the time there's a way to write python2 and 3 compatible code, so which means the transition can go smoothly.
Also I think you're too harsh on the analogy, most of the time there's a way to write python2 and 3 compatible code, so which means the transition can go smoothly.
This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
I think a fairer interpretation of the situation is "Well, we have to rewrite and test all this code anyway, so the barrier to picking another language to go forward with is quite low right now."
That's a corollary to this, for sure, particularly if there's another language that would be more appropriate. That said, the OP seemed to be moving on primarily out of annoyance. Assuming that's the case and Python is the best language for the project (keeping in mind things like "I can hire the same quality people who WANT to work in this language), I stand by my (still slightly tongue in cheek) position.
A question comes to my mind on the desires of developers to work on Python projects. Would it be fair to say Rust or Go might have more desirability these days? The WANT question makes me think this is a bit more than simple annoyance but provides an excuse to travel to greener pastures.
It’s a bit less absurd when the person gave the reason that they feared a similar breaking python release in the near future. This might still be incorrect of them, but to me anyhow it’s not strange or silly reaction.
>Instead, I spent my time moving to languages that had more respect for their invested users.
I’m not sure what more they could have done. Python 2 was released almost two decades ago, with an original planned sunsetting that got pushed back to 2020. That’s plenty of time and respect for their users.
>All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
You’re free to stick with python 2 for as long as you’d like. You’re free to fork the project and continue develop it. To say there is no benefit to new and evolving languages is odd and short-sighted.
I’m not sure what more they could have done. Python 2 was released almost two decades ago, with an original planned sunsetting that got pushed back to 2020. That’s plenty of time and respect for their users.
>All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
You’re free to stick with python 2 for as long as you’d like. You’re free to fork the project and continue develop it. To say there is no benefit to new and evolving languages is odd and short-sighted.
> I’m not sure what more they could have done.
Not broken 2? None of the breaking changes in 3 were necessary.
Not broken 2? None of the breaking changes in 3 were necessary.
the first part of this captures how my company has handled python 2/3. there’s probably 1-2 hundred thousand lines of python 2 that works well and is largely in maintenance mode. if we were going to change it, it would be a piecemeal step by step replacement to a different
language, not upgrade to python 3. going from 2 to 3 in sufficiently large code bases is already a language rewrite. the company has moved on from python
the zero benefit is where you show that you didn't even try to think about it. missed opportunity to stay silent.
(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...)
That seems like a very specific example...
That seems like a very specific example...
I had exactly _zero_ blocking issues. The only relevant thing for me is that I keep reaching for StringIO and urlparse (and friends) and they're used differently now.
_Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke.
Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.
_Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke.
Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.
If you were writing major libraries that needed to work on both 2 and 3 like many of us were, I suspect your opinion would be different. It was never a case of 'oh we'll just switch to 3 now' because that's not at all how it worked.
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1].
I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded.
1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1].
I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded.
1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...
Let me put it this way: at $dayjob, where 'IT' isn't particularly specialized, we just celebrated a switch to SQL Server from a homegrown database written in the early 80ies.
I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.
I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.
I was pretty confused by the change to str object, until I sat down to properly think it through. I wrote an SO response in case others were snagged on it. https://stackoverflow.com/questions/5471158/typeerror-str-do...
> Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done.
I suppose you don't use Java.
I suppose you don't use Java.
> (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?
Isn't what code review and CI/CD is for?
Isn't force-merging without waiting for code review or test results what managers are for?
Sounds like you should get a new manager.
As a manager one should be extra careful to be _seen_ eating your vegetables, flossing your teeth and getting your code reviewed.
(What you do in private is a different matter. In some companies office politics can require some skullduggery.)
As a manager one should be extra careful to be _seen_ eating your vegetables, flossing your teeth and getting your code reviewed.
(What you do in private is a different matter. In some companies office politics can require some skullduggery.)
It was just a joke, but we're talking about a manager who "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..."
[deleted]
Totally disagree. There's rarely a good reason to break backwards compatibility. It's beyond rude to choose to break compatibility and then force all your users to fix it.
The Apple comparison is a bad one since Apple controlled the whole thing.
The Apple comparison is a bad one since Apple controlled the whole thing.
How well would that work on MacOS?
you are comparing an open source language to the apple os.
Yes, and? GP was very clear that this is a comparison to show how quickly it can be done when it's proprietary and not open source.
What 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 to Python 2's docs? I think it would be quite instructive.
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 to Python 2's docs? I think it would be quite instructive.
I cannot agree enough.
As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
Me three! It happens all too often that an example Python script fails in one, then succeeds in the other. I'm also a casual Python user, trying to ramp up because of its obvious popularity and utility. I wish that the basic syntactical changes could have been designed to be more backward-compatible. But, eventually I suppose, python2 will just be a footnote in history.
Same situation here. Trying to jump on this bandwagon and finding it's a slithering target.
I just wish they'd named it something different. If there's neither forward nor backward compatibility, I'd argue they're not the same language and should not have the same name.
I just wish they'd named it something different. If there's neither forward nor backward compatibility, I'd argue they're not the same language and should not have the same name.
Most languages have had breaking changes at some point in their history. Even the language known as "Perl 5" had them in almost every version.
In the real world, I've found Perl scripts written in 1999 (and poorly - as they were written by me in my teens) will still run in 2019. It's basically the policy that even language mistakes won't be undone:
https://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBIL...
https://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBIL...
This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.
It really shouldn't be beyond the wits of the hackage developers to include a normative URL in old docs...
100% agree. I think every Python 2 doc page should have a big banner on top mentioning the EOL status of Python 2 and linking to the coresponding Python 3 page (if there is one). Googling "python + keyword" far too often still takes you to the Python 2 docs.
> I think every Python 2 doc page should have a big banner on top mentioning the EOL status of Python 2 and linking to the coresponding Python 3 page (if there is one).
I'd support that if every Python 3 page had a link saying "if you're still a sorry SOB stuck on Python 2, here's the link to the related library." It's just as bad for Python 2 developers, it's roughly a 50/50 shot of whether you get docs for 2 or 3.
I'd support that if every Python 3 page had a link saying "if you're still a sorry SOB stuck on Python 2, here's the link to the related library." It's just as bad for Python 2 developers, it's roughly a 50/50 shot of whether you get docs for 2 or 3.
I'm not sure this is the right place, but maybe open an issue here?
https://bugs.python.org/
Or email the mailing list for more help?
https://mail.python.org/mailman/listinfo/python-list
https://bugs.python.org/
Or email the mailing list for more help?
https://mail.python.org/mailman/listinfo/python-list
I was about to file a bug, but they found out it already exists, just hasn't been merged into the 2.x tree.
- https://github.com/python/cpython/commit/46ed90dd014010703c7... - https://github.com/python/cpython/pull/13638 - https://github.com/python/cpython/blob/master/Doc/README.rst...
- https://github.com/python/cpython/commit/46ed90dd014010703c7... - https://github.com/python/cpython/pull/13638 - https://github.com/python/cpython/blob/master/Doc/README.rst...
Python 2.7 isn't yet unsupported, so it doesn't compare to the deprecated Postgres version you linked to. Click through to the oldest _supported_ Postgres version, and it isn't clear when _it_ will lose support - no banners at all - , just like the currently supported Py 2.7.
That's true.
And because of changes in PostgreSQL versioning, people don't release that the oldest support version (9.3) is rather old.
PostgreSQL 9.6 was released in 2016, 10 in 2017, and 11 in 2018.
But PostgreSQL 9.3 was released way back in 2013...not quite as old as Python 2.7 but close.
And because of changes in PostgreSQL versioning, people don't release that the oldest support version (9.3) is rather old.
PostgreSQL 9.6 was released in 2016, 10 in 2017, and 11 in 2018.
But PostgreSQL 9.3 was released way back in 2013...not quite as old as Python 2.7 but close.
Django has a similar banner at the top if you (perhaps via Google) get to a page about a feature in a deprecated version. So it's not like this is uncommon in the Python world. Hopefully they get that fixed soon.
HL7.org has a banner on every version of the FHIR spec with a different message depending on the version. http://hl7.org/fhir/
I would discourage this, as it will lead to banner blindness. Only pop a banner up if you want the user to read and react to it. Otherwise, they'll just get used to the banner being there and will often times not read it at all.
It seems to work pretty well for everyone. FHIR developers are keenly aware of the version of the spec they are (currently) targeting.
Also they are color coded.
Also they are color coded.
In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet.
In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now.
For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backing it up.
In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now.
For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backing it up.
Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short.
Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes.
Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
It's interesting seeing who the holdouts are, though. Less than a year ago, the CEO of Sentry (the crash reporter) locked a Github thread with essentially "we'll get there when we get there, sometime in or after 2020." But then, as late as 2016 their stance was pretty much that they would never migrate, so I suppose it's not surprising that they aren't super prepared for it:
https://github.com/getsentry/sentry/issues/8806#issuecomment...
https://github.com/getsentry/sentry/issues/1152#issuecomment...
I mean, even supervisord is migrated at this point, and it was a long-time laggard.
https://github.com/getsentry/sentry/issues/8806#issuecomment...
https://github.com/getsentry/sentry/issues/1152#issuecomment...
I mean, even supervisord is migrated at this point, and it was a long-time laggard.
Calibre is another well known case, and they don't plan to migrate.
Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are refusing to migrate. (I'll probably have to find an alternative to ebook-convert, the command line tool that's the only part of Calibre I use, or maybe I'll rewrite it in Python 3 myself.)
Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are refusing to migrate. (I'll probably have to find an alternative to ebook-convert, the command line tool that's the only part of Calibre I use, or maybe I'll rewrite it in Python 3 myself.)
The only good part of calibre is the `ebook-convert` commandline tool that has a stupid-simple interface (polar opposite of the gui) and handles all kinds of formats that pandoc doesn't.
The gui, Calibre proper, is a total nightmare. Functional, but my god is it esoteric and ugly. I've heard people actually use that gui as their primary ebook reading software and I just can't fathom how they find that tolerable.
https://manual.calibre-ebook.com/generated/en/ebook-convert....
The gui, Calibre proper, is a total nightmare. Functional, but my god is it esoteric and ugly. I've heard people actually use that gui as their primary ebook reading software and I just can't fathom how they find that tolerable.
https://manual.calibre-ebook.com/generated/en/ebook-convert....
I dislike Calibre main GUI as well. It looks a bit dated and all, but really convenient for downloading books from Userfiction forums like Spacebattles via the Fanficfare plugin. Also good for simple editing of ebook metadata. Built-in ebook-viewer is highly configurable with custom keybindings and themable with custom CSS.This is my setup
https://imgur.com/a/nlAAlZn
https://imgur.com/a/nlAAlZn
I use Calibre as my primary e-book reader. I don't see many alternatives on Linux.
I basically use Calibre ebook viewer for its configurability and customization. If you want a good ebook reader, give Foliate (https://github.com/johnfactotum/foliate) a try. That and Bookworm
(https://github.com/babluboy/bookworm) are the best standalone ebook readers I've seen in Linux.
Other than having a simpler layout I don't really see either as better than calibres reader. What's better other than looks?
That's not true.
https://github.com/kovidgoyal/calibre/blob/master/README.pyt...
https://github.com/kovidgoyal/calibre/pull/870
If that's the case, I'm glad to see things are changing. Up until very recently, there seem to have been no plans to switch: https://bugs.launchpad.net/calibre/+bug/1714107
> No, it doesn't [need to convert to Python 3]. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.
> No, it doesn't [need to convert to Python 3]. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.
> I am perfectly capable of maintaining python 2 myself.
That's a very strange quote. I want to have this much self-confidence.
That's a very strange quote. I want to have this much self-confidence.
Calibre is, in fact, migrating. There are at this point dozens of commits over the past few months to that goal. Not sure what changed his mind.
Reality? You can maintain an absurd, unintuitive, dated UI by yourself fairly easily, but even someone who pushes out two minor updates per week is going to be taking on a little too much in my opinion if they believe they can also support a fork of a major language.
And make a gnome core app with GTK3? That would pretty cool :)
His responses leave an incredibly sour taste in my mouth. Not only is he obviously short sighted with his "Python 2 is not the past and Python 3 is not the future" but all his responses just sound like someone who got up on the wrong side of the bed. Every morning.
You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.
But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
I often hear this, but I just don't see this working in practice. A very similar example I have experience with, I've often worked with people who tried to write code that would be "compatible with Windows" (I primary work in a Linux environment). It makes the code more difficult to read and as soon as you try and run it in Windows it fails spectacularly.
You can write code that's compatible with both Python 2 and 3, but I don't think you can expect to be using Python 2 exclusively and write code that works well in Python 3 unless you're constantly running it with Python 3. Especially, if you don't have much firsthand Python 3 experience. This is much easier if your code is isolated from those dependencies and you write tests that run in both Python 2 and 3, but that's quite a bit more of a commitment than you seem to be implying.
You can write code that's compatible with both Python 2 and 3, but I don't think you can expect to be using Python 2 exclusively and write code that works well in Python 3 unless you're constantly running it with Python 3. Especially, if you don't have much firsthand Python 3 experience. This is much easier if your code is isolated from those dependencies and you write tests that run in both Python 2 and 3, but that's quite a bit more of a commitment than you seem to be implying.
There are a ton of open source projects that have done python 2/3 simultaneously in practice.
I get your point though about not being able to run full integration tests due to dependencies. Still, if you were making a good effort to keep the code Python 3 compliant, it would make upgrading much easier.
Also, my other suggestion- contributing to Python 3 compatibility for modules you depend on! That will give you Python 3 experience :)
I get your point though about not being able to run full integration tests due to dependencies. Still, if you were making a good effort to keep the code Python 3 compliant, it would make upgrading much easier.
Also, my other suggestion- contributing to Python 3 compatibility for modules you depend on! That will give you Python 3 experience :)
Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought.
It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.
It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.
Okay, I did it.
Python 2.7: https://repl.it/repls/OrchidDirtyNotification
import subprocess
import re
import yaml
output = subprocess.check_output(['ls', '-l'], universal_newlines=True)
matching_lines = []
for line in output.splitlines():
if re.search(r'total', line):
matching_lines.append(line)
with open('matching_lines.yaml', 'w') as f:
f.write(yaml.dump(matching_lines))
Python 2.7: https://repl.it/repls/OrchidDirtyNotification
Nice. Yeah my life got a lot easier when I learned about `universal_newlines` changing the subprocess return type under Python 3.
The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree.
A taste: https://github.com/ros-infrastructure/rosdistro/search?q=utf...
The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree.
A taste: https://github.com/ros-infrastructure/rosdistro/search?q=utf...
This program would crash with a UnicodeEncodeError upon encountering any file with a non-latin character in its name on Windows with Python 3.5 or earlier.
I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.
I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.
[deleted]
No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.
The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago.
This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
Ah, I see the confusion. In this case, "easily" is relative. The assertion "you could easily write Python 3 compatible code" was in response to the (implied?) assertion "you can't do anything to migrate unless your dependencies are migrated". Perhaps "simply" would have been a better word choice than "easily". To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem.
> To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem
Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
It doesn't take considerably more time.
At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years.
And I've been writing some of my code 2/3 compatible since 3.4.
At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years.
And I've been writing some of my code 2/3 compatible since 3.4.
[deleted]
> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy.
This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
> This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3.
[Edit: gas -> gasoline]
While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3.
[Edit: gas -> gasoline]
I try to write compatible code myself too, and the only reason it's "zero effort" to run in Python 3 is that I've already invested said effort when making it compatible. Getting strings and paths and stdio to be cross-compatible and working correctly in both 2 and 3 can be quite painful in my experience. Which was kind of my point with the vehicle analogy. It requires a significant investment that you're ignoring, and lack of enough underlying support to justify it during that time.
Driving an EV without charging stations is (nearly) useless. You can still run Python 2-3 code with a Python 2 interpreter with no significant consequence.
EV drivers don't need charging stations at all if they have an open plug at home or at work. The metaphor still sort of works that Python developers had plenty of time where maybe they didn't have enough charging stations on the wide open highway roads of Production to use Python 3 there, but certainly could have been happy to use an EV to commute from home (hobby projects) to the work parking lot (side projects, automation projects, new projects) and back while they waited for those "charging stations" to be built.
I don't want to debate the amount of shoehorning necessary to validate the metaphor. We all understand concretely the issue at hand, the metaphor is only obfuscating at this point.
I feel like there were 3 steps:
- 2008-2012 Python 3 becoming usable (byte formatting, six library)
- 2012-2016 Libraries (Django, etc) becoming compatible
- 2016-today Applications (Trac, Ansible, Chrome[1], etc) becoming compatible.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=942720
- 2008-2012 Python 3 becoming usable (byte formatting, six library)
- 2012-2016 Libraries (Django, etc) becoming compatible
- 2016-today Applications (Trac, Ansible, Chrome[1], etc) becoming compatible.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=942720
well what if your best guess was that py2 would never actually be deprecated. Certainly in the early tens I had serious doubts.
The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now".
If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
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.
I get this, though: porting code affects all parts of the code base, so it generates git conflicts all the time. It's way more of a pain to do than routine feature development or refactors. It gets difficult to have part of the team work on features while another group works on the port to a new version, because that generates a ton of conflicts. It's easier to get the entire team working on the port.
I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.
I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.
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."
> porting our library
Library, as is most open source libraries out there, sure.
For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
Library, as is most open source libraries out there, sure.
For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when the deadline was postponed by 5(!) years.
Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
This x 1000.
“The free libraries we chose to depend upon haven’t migrated.”
Do you have programmers?
“Of course.”
Put them to work.
“We have other priorities.”
Well then. Your choice, your outcome.
“The free libraries we chose to depend upon haven’t migrated.”
Do you have programmers?
“Of course.”
Put them to work.
“We have other priorities.”
Well then. Your choice, your outcome.
This is dumb. You're blaming people who probably don't get to call the shots. The managers who do have the ability to make different decisions are, themselves, often under the gun to meet other commitments.
Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.
The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.
Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.
The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.
> You're blaming people who probably don't get to call the shots.
I think he's blaming organizations, not engineers.
I also think organizational dysfunction is a problem that isn't a technical problem that the Python project has the capability or duty to solve.
I think he's blaming organizations, not engineers.
I also think organizational dysfunction is a problem that isn't a technical problem that the Python project has the capability or duty to solve.
> You're blaming people who probably don't get to call the shots.
No one is doing that.
OTOH, it's not PSFs job to protect developers from bad management.
No one is doing that.
OTOH, it's not PSFs job to protect developers from bad management.
There is also the third choice - you don't migrate and keep doing your job (developing features) on the legacy code base. Things like certificates will have ad-hoc solutions pushed whether you like it or not, and the language will keep trundling along.
If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.
This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.
This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.
If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.
This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.
This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.
This attitude is ridiculous.
I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline?
Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it.
More programmers != better results or faster delivery. Your solution is just going to create more problems.
I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline?
Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it.
More programmers != better results or faster delivery. Your solution is just going to create more problems.
You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate.
At no point do you have to wait on anyone else, you choose to.
At no point do you have to wait on anyone else, you choose to.
You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.
If there is significant demand for solving the problem your fork solves, others will migrate to it. This is made harder when the main solution gets to squeak along for 10 extra years on a version of the language that should no longer get first-party support. Of course there is going to be less demand for that Py3 solution when there is no immediate consequence for continuing on Py2. Killing security update support for 2 will boost the demand for libraries using 3, and make it more likely that your fork gets merged or becomes the defacto standard.
The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.
The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.
How are they supposed to migrate if I can't openly host my solution because it was developed on company time? Merging back into the original project is one thing, but making your solution available some other way is a whole other story.
This is the reality of having lots of open source dependencies. Important changes/bugs may exist, and the maintainers are under no obligation to fix them to suit your business needs. If you want them fixed, you contribute to the code base (or fork it) and fix it.
Still better than my last programming job where the vendor of a vital piece of HW had provided a C++ API (also vital), but refused to provide dlls that would work in anything newer than VS2010. At least with open source you can do something about it.
Still better than my last programming job where the vendor of a vital piece of HW had provided a C++ API (also vital), but refused to provide dlls that would work in anything newer than VS2010. At least with open source you can do something about it.
You shouldn't take "Do you have programmers?" too literally.
Programmers ~= Resources ~= Money
=> If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
Programmers ~= Resources ~= Money
=> If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
The time frame is 12 years though, since the sunset was originally announced in 2008.
A lot of libraries refused to migrate before Python 3.5(?) came out which was ~4 years ago. IIRC earlier Python 3 versions had performance regressions compared to Python 2.
This. For most organizations, the effective window has only been 2-3 years.
Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.
Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.
> Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short.
Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.
Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.
It was longer than Apple’s move to 64 bit apps on the iPhone.
Actually, depending on what action you pin dates to, it was twice as long.
One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
Actually, depending on what action you pin dates to, it was twice as long.
One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
That's a pretty low bar. I still think that move by Apple was pretty terrible. Especially given that it's 100% impossible to downgrade iOS (your last point).
And it’s entirely impossible to run 32 bit apps on newer Apple ARM chips. There is always a cost to keeping old APIs or in Apple’s case, old silicon.
It's actually longer than android has been alive...
But it's not commercial, and you had four years of guidance.
I feel like this the python community has been the epitome of class regarding communication during a transition.
I feel like this the python community has been the epitome of class regarding communication during a transition.
In 2014, things were not quite ready so they extended it 6 more years. If you were upset by this you really need to get out of software development.
Windows 10 Enterprise LTSB 2015 (the original long term support version of Windows 10 Enterprise) doesn't support installing .Net 4.7 at all.
There are an increasing number of applications which require .Net 4.7, we found one early this year.
Promising "10 years of support" for a product is great, but if/when other vendors decide to undercut this, you can still be SoL :(
There are an increasing number of applications which require .Net 4.7, we found one early this year.
Promising "10 years of support" for a product is great, but if/when other vendors decide to undercut this, you can still be SoL :(
I'm pretty sure there will be more than one commercial offer for Python2 support in the future.
This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use?
Where they only release security updates and no breaking changes?
Where they only release security updates and no breaking changes?
I think there are plenty of programming languages (maybe even most of them?) which take backward compatibility as a very serious goal. Obviously there's a balance between "don't break user space!" and fixing major problems (e.g., C's gets()), and most of the major ones seem to lean toward the former.
At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.
At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.
Common Lisp code tends to be very stable long term. Occasionally people dig out some old code from the 60s or from really old books and papers and it will just run on modern systems. Maybe with slight modifications since the standard was finalized in 1994 and there were some changes to the way scope works in common lisp compared to say the older mac lisp, but anything written since that is written in portable standard compliant common lisp is pretty much guaranteed to continue working while there are still people willing to maintain common lisp compilers for whatever hardware exists in the future. It's actually extremely comforting to be able to come back to a project after not touching it in a few years and have every test pass even if I upgraded all the dependencies(as long as I picked the right dependencies that is :), lispers tend to be pretty conservative about breaking changes in mature and popular libraries.
"Built for", probably not. "That guarantees support for", some Windows releases and Microsoft stacks ended up doing more or less that, be it by accident or strategy. Probably some mainframe-related stuff too, being the only sort of thing around before the late '80s and possibly still in use.
There is also the case of Oracle, which defines support as "you can read our knowledge base and we will answer a phone before telling you it can't be done", meaning their support is literally for life (of the company). And they still manage to screw it up by deleting old KM articles...
Everything else in IT goes towards shorter and shorter support windows, because the field is always in flux and change (or rather churn) accelerates every year.
There is also the case of Oracle, which defines support as "you can read our knowledge base and we will answer a phone before telling you it can't be done", meaning their support is literally for life (of the company). And they still manage to screw it up by deleting old KM articles...
Everything else in IT goes towards shorter and shorter support windows, because the field is always in flux and change (or rather churn) accelerates every year.
Anything based on real standards - C, POSIX/SUS shell, SQL, SGML, and others - is made without half-life and generational churn.
Many compiled languages might have breaking changes at the language level but are still compatible at the dll/binary level. Java 1.0 and C# 1.0 code can still be compiled and run on modern JVMs and CLRs, and rust 2015 and 2018 work together as well.
C18 is basically backwards compatible with C89. That's 30 years. The only function removed from stdlib is gets(), which was deprecated in C99.
Excel spreadsheets, which contain an astonishing amount of business logic, tend to be backwards-compatible far longer than the OSes that Excel itself runs on.
Food for thought, anyway.
Food for thought, anyway.
I would have said Java, but then they decided to shove modules down everyone's throat.
Wouldn't Java 1.0 code still work in Java $LATEST even with modules? As i understand it the question was about keeping stuff working, not refusing to add new stuff.
1.1 is what would still work. There was not much Java 1 code in existence.
Java 1.4 to 5 was annoying and the last release to introduce a lot of source code in compatibility. Which was sometime in 2004. Modules is mostly figuring out what switches to set on startup, not so much refuses to work.
I would say the Perl but then the Perl 6 fiasco made Python 3 look like a model citizen for upgrading code.
Perl5 is not being EOL'ed in favour of Perl6. When the time does come around for Perl5, I would guess that only a small fraction would migrate to Perl6.
> I can't imagine they made this decision without at least some data backing it up.
Mind that there is a feedback loop between data of current usage and an eol announcement.
If they announce an EOL close by this creates pressure to migrate.
Mind that there is a feedback loop between data of current usage and an eol announcement.
If they announce an EOL close by this creates pressure to migrate.
In my mind, I kinda hope that data they used to back this decision up was asking "Hey, all you other volunteer Python language devs? How many of you want to work on the old Python2 codebase still? How many of you would prefer to be working on Python3? OK, that's just about unanimous. How about we all get drunk on Newyears and shut it down on Jan 1st?"
You can still get Microsoft Windows XP support today. If you're prepared to pay enough.
I wonder how many of the people who're upset by this have ever or ever worked for companies that've ever sent anything more than pocket change to the people Python?
You can still get Microsoft Windows XP support today. If you're prepared to pay enough.
I wonder how many of the people who're upset by this have ever or ever worked for companies that've ever sent anything more than pocket change to the people Python?
Personal use can be quite different to business use cases. For many companies the conversion can be quite horrific, they might be quite happy to pay for support for older versions.
normalhuman(6)
>In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet.
You could work on porting them or be part of that effort?
You could work on porting them or be part of that effort?
>If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you.
Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team if just security fixes are involved...
Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team if just security fixes are involved...
Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it.
Python 2.7 was released 1 decade ago. That's quite a long transition time.
Python 2.7 was released 1 decade ago. That's quite a long transition time.
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 < 10; i++). Other more advanced and fully-featured system languages like C++, Rust or Go have a different story to tell and making them backward compatible comes at a significant maintenance cost.
Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
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.
By the way, recently I realized that what I want is a language that does less instead of doing more. After all all these niceties with ranges and iterators are just syntactic sugar. Write pythonic code and face problems when porting this algorithm to C because C has nothing of Python niceties, which stop looking so nice at this point. Write non-pythonic C-like code without classes but with `__slots__` and functions all the way down and get not only the code that can be ported much easier to C and many other languages, but, surprisingly, also the code that is much more accessible and easier to reason about.
Not really. :-)
ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled.
C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing lots of people tripped up over was endianness (sp?).
C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing lots of people tripped up over was endianness (sp?).
To be fair though, in 10 years time I'll still be able to build the last release version of Python2 (quite likely using a modern-in-2029-C-compiler) and use it to run whatever stone age Python2 code in need to run.
What people seem to be getting uptight about here, is that the volunteer Python language devs have collectively chosen to not fix any bugs or security problems discovered in the older Python2 language interpreter. I can't quite get my head around what the equivalent for that in C would be? There kinda _are_ no "language security features" in C, right? C is the archetype "How powerful a gun would you like to shoot yourself in the foot with today" language.
What people seem to be getting uptight about here, is that the volunteer Python language devs have collectively chosen to not fix any bugs or security problems discovered in the older Python2 language interpreter. I can't quite get my head around what the equivalent for that in C would be? There kinda _are_ no "language security features" in C, right? C is the archetype "How powerful a gun would you like to shoot yourself in the foot with today" language.
That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is.
A couple of lines change does not qualify as a port to me. It was less of a change than from one minor release of a modern language to another.
Prior to the ANSI standard there were many C compilers on different machines with different architectures.
Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here.
The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week.
You probably were very lucky with that project of yours.
Even the way we have it nowadays C is... hard to formalise.
Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here.
The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week.
You probably were very lucky with that project of yours.
Even the way we have it nowadays C is... hard to formalise.
> I just compiled a pretty large project from the stone age using a modern day compiler.
Ok, now do the reverse. ;)
The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.
Ok, now do the reverse. ;)
The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.
> Ok, now do the reverse. ;)
Excellent point, conceded.
But backwards compatibility is the more useful direction to me, I can see however that if your job is to take a modern day application and compile it for a platform for which there is no modern day compiler that you're going to be in a special kind of hell for a long long time if the project has any size at all.
Excellent point, conceded.
But backwards compatibility is the more useful direction to me, I can see however that if your job is to take a modern day application and compile it for a platform for which there is no modern day compiler that you're going to be in a special kind of hell for a long long time if the project has any size at all.
touché :)
C is also a living language to some degree: http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log...
It still requires dialect selection: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Optio... http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual....
Not to mention that a system library is only as portable as the code you write for it, since inherently there’s usually a very small standard library of functionality that can be assumed across platforms. And all the support for systems generally rests on the system developer shipping support with C headers, etc.
Now it could be argued that C dialects are far more compatible with each other than Python 2 to Python 3, it could also be argued that linkers allow for code targeting one dialect to call code compiled for another dialect...
Once you go down that rabbit hole, though, there’s an argument that as most scripting languages are basically VMs with JIT compilation, then just like .NET and JVM, there’s nothing preventing scripting languages from inherently supporting multiple dialects via compiled intermediary representations...
But I digress... :)
It still requires dialect selection: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Optio... http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual....
Not to mention that a system library is only as portable as the code you write for it, since inherently there’s usually a very small standard library of functionality that can be assumed across platforms. And all the support for systems generally rests on the system developer shipping support with C headers, etc.
Now it could be argued that C dialects are far more compatible with each other than Python 2 to Python 3, it could also be argued that linkers allow for code targeting one dialect to call code compiled for another dialect...
Once you go down that rabbit hole, though, there’s an argument that as most scripting languages are basically VMs with JIT compilation, then just like .NET and JVM, there’s nothing preventing scripting languages from inherently supporting multiple dialects via compiled intermediary representations...
But I digress... :)
That's not really a fair comparison. Python 2 probably _will_ be supported for decades to come, just not necessarily by the PSF. I'm sure that 99% of people and organizations supporting C 40 years ago do _not_ support C today.
Very few people write pre-ANSI C code today though, and the language itself was last updated in 2011.
I'm sure people wouldn't gladly accept C code written for a 47-year-old compiler today.
I'm sure people wouldn't gladly accept C code written for a 47-year-old compiler today.
> the language itself was last updated in 2011
The current standard languauge is C18.
The current standard languauge is C18.
agreed!
I know you're writing tongue-in-cheek, but if you look at early C code you'll find it's not really supported today. The Lions book is full of "interesting" type magic, for example.
However the best analogy for python 2to3 is probably the prototyping changes of ANSI C, and we similarly offloaded the conversion of that code to external tools (protoize(1) and unprotoize(1)).
However the best analogy for python 2to3 is probably the prototyping changes of ANSI C, and we similarly offloaded the conversion of that code to external tools (protoize(1) and unprotoize(1)).
I wonder if they would have saved themselves five years of grief if they had done this five years ago.
I don't think so. Five years ago a lot of the community wasn't ready and it probably would have resulted in the community splitting in two.
Now many important libraries have already moved to being Python 3 making the whole Python 2 ecosystem feel frozen.
Now many important libraries have already moved to being Python 3 making the whole Python 2 ecosystem feel frozen.
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 code now is just criminal.
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 code now is just criminal.
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.
Well, it seems you were writing py3 code in py2, as much as was possible, so I wouldn't lump you in yo the criminal camp.
Not everywhere had that foresight.
Not everywhere had that foresight.
I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago.
Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?
Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?
macOS says they’ll stop supporting scripting languages out of the box someday, so targeting Homebrew is probably best.
[deleted]
[deleted]
I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work.
Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
There is Tauthon[1] which backports Python 3 features to 2 and seems to do the "actual work". It has been around a while.
It was also posted in this thread below by the current maintainer of the project but for some reason that comment was downvoted to [dead].
By reading a bit around about it, i do get the impression that the Tauthon developers face a bit of hostility from the Python community, so i'm not sure how viable it'll be in the long term. I suppose it depends on how stubborn the Tauthon developers are :-P
[1] https://github.com/naftaliharris/tauthon
It was also posted in this thread below by the current maintainer of the project but for some reason that comment was downvoted to [dead].
By reading a bit around about it, i do get the impression that the Tauthon developers face a bit of hostility from the Python community, so i'm not sure how viable it'll be in the long term. I suppose it depends on how stubborn the Tauthon developers are :-P
[1] https://github.com/naftaliharris/tauthon
It wasn't downvoted to dead - the author has been banned, they've copied dang's comments to their profile.
(Unlike other forums, banned users can still post, but their posts require someone with showdead on to vouch for it before it can be seen).
(Unlike other forums, banned users can still post, but their posts require someone with showdead on to vouch for it before it can be seen).
RHEL 7 depends on python 2.7 and will have security/maintenance support till June 2024. So for security updates, I guess we can just track RHEL7/CentOS7 python 2.7.
Correct
Also the longer a software is around, the lower the chance of some showstopper showing up (not 0% chance though)
What's most likely is that one important library in 2.7 stops talking to some upgraded system version (think OpenSSL for example) then what depends on it stops working.
Also the longer a software is around, the lower the chance of some showstopper showing up (not 0% chance though)
What's most likely is that one important library in 2.7 stops talking to some upgraded system version (think OpenSSL for example) then what depends on it stops working.
> Many will complain, but few will do the actual work.
That's opensource in a nutshell.
If there are any big shops stuck on Python 2 then they will probably throw a resource or two at this. If there are big dists using Python 2 they will do the same.
That's opensource in a nutshell.
If there are any big shops stuck on Python 2 then they will probably throw a resource or two at this. If there are big dists using Python 2 they will do the same.
From what I can tell, even Google is moving to python 3 (some of their previously python 2 only tools (like repo) have gained ‘experimental’ python 3 support) this year, so they’re probably not going to be doing the work.
> then they will probably throw a resource or two at this
Which, I'd guess, is probably gonna be 3 or 4 orders of magnitude more money than they've ever spent supporting Python2 (or 3) devs in the 10+ years they've built their own businesses on it while they sat on their hands and ignored the project's urging to upgrade to Python3...
Not a lot of sympathy from me for "big shops stuck on Python2"...
Which, I'd guess, is probably gonna be 3 or 4 orders of magnitude more money than they've ever spent supporting Python2 (or 3) devs in the 10+ years they've built their own businesses on it while they sat on their hands and ignored the project's urging to upgrade to Python3...
Not a lot of sympathy from me for "big shops stuck on Python2"...
Canonical or Redhat will probably sell services related to supporting Python 2 and/or porting your code to Python 3.
I'm no Python insider, but Google has quite a lot of projects based on Python 2, including build scripts for recently released software, so I'm guessing they could at some point maintain their own Python 2 branch (which, again, I'm guessing is much less work than porting a huge amount of script code over to 3 for no material benefit).
They already have one - look in their type checker repo for patches that add certain Python 3 features (type annotations) to Python 2.
That's sort of hilarious... What are the incentives that prevent Google from upgrading their python 2 scripts to python 3? I guess it's more productive globally to stick with a supported version of Python 2.
Not the one you're responding to, but there are many cases where Python is used in the role of a shell script replacement eg. build scripting and test suite automation that wouldn't benefit from migration and, in fact, would suffer from half-assed migration attempts with little or no real-world testing.
Ubuntu 18.04 has support for Python 2.7 til 2028 I think.
Only for paying customers, general support will end in 2023.
There's a list of some enterprise Linux distros and their default python versions and their end-of-life dates on the Wikipedia article for CPython
https://en.wikipedia.org/wiki/CPython#Distribution
https://en.wikipedia.org/wiki/CPython#Distribution
The biggest problem is having a place to organise.
The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name.
Finding volunteers who are willing to get sued to work on Python will be hard.
The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name.
Finding volunteers who are willing to get sued to work on Python will be hard.
Are you referring to that "Python 2.8" thing [1] that happened some years ago? A comment from PSF [2] makes it clear that they don't have any issue with people continuing to develop their Python 2 codebase further. It is what their open source explicitly permits after all.
They do have issue with people using a trademarked name and not making it clear that their work isn't endorsed by the Python Foundation.
[1] https://www.naftaliharris.com/blog/why-making-python-2.8/
[2] https://news.ycombinator.com/item?id=13147972
They do have issue with people using a trademarked name and not making it clear that their work isn't endorsed by the Python Foundation.
[1] https://www.naftaliharris.com/blog/why-making-python-2.8/
[2] https://news.ycombinator.com/item?id=13147972
For me, if I want most existing python2 programs to work, I'd want to release my program as called "python", so "#!/usr/bin/env python" continued to work.
If I'm not allowed to do that, then you are already adding a lot of friction to continuing to support existing python installs.
Although, I wonder if you could claim you need to call it that for the programs to work?
If I'm not allowed to do that, then you are already adding a lot of friction to continuing to support existing python installs.
Although, I wonder if you could claim you need to call it that for the programs to work?
You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy (https://www.python.org/psf/trademarks/) explicitly allows most sorts of freely distributed Python-related products to use the name without permission:
> Use of the word "Python" in the names of freely distributed products like IronPython, wxPython, Python Extensions, etc. -- Allowed when referring to use with or suitability for the Python programming language.
We can quibble about whether a Python 2 fork would technically meet the definition here, but it seems to me that it would meet it at least as much as IronPython does; going after such a fork would contradict the rule implied by the examples in this section, even if it doesn't unambiguously violate the definition. I think they've already granted the public the right to use the word "Python" in a Python 2 fork and couldn't successfully sue over it now even if they wanted to.
What's your basis for suggesting that they've threatened to do so?
> Use of the word "Python" in the names of freely distributed products like IronPython, wxPython, Python Extensions, etc. -- Allowed when referring to use with or suitability for the Python programming language.
We can quibble about whether a Python 2 fork would technically meet the definition here, but it seems to me that it would meet it at least as much as IronPython does; going after such a fork would contradict the rule implied by the examples in this section, even if it doesn't unambiguously violate the definition. I think they've already granted the public the right to use the word "Python" in a Python 2 fork and couldn't successfully sue over it now even if they wanted to.
What's your basis for suggesting that they've threatened to do so?
Sorry, I shouldn't assume people know the same things I know.
I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one:
https://github.com/naftaliharris/tauthon/issues/47
In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".
I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one:
https://github.com/naftaliharris/tauthon/issues/47
In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".
That is an absurd mischaracterization of the conversation. Guido’s response to the “py28” name was only, “Doesn’t work for me, sorry.” The “lawyers” response was specifically a response to an aggressive, insulting post from another poster. That other poster said that Guido should be disregarded, suggested names that would clearly get lawyers involved if chosen, accused Guido of sabotaging Python 2, and characterized Guido’s naming objections as silly. To Guido’s (virtual) face, no less! He was described by the original poster in that thread as hostile, antagonizing, and rude. Any reasonable reading of that single sentence post from Guido is of his giving up – throwing up his hands and saying the equivalent of “Well, whatever, then.”
---
gvanrossum: Isn't the whole point that we're trying to solve this without lawyers?
[redacted]: The whole point is that you've been sabotaging Python 2 for years and when someone does what needed to be done from the start, you come up with silly objections.
gvanrossum: OK, bring in the lawyers.
---
Just don’t appropriate a name what’s not yours, and you can maintain all the Python 2.x you want. Pathfinder[1] couldn’t call itself D&D 3.6 – Tauthon or anyone else can’t make things called Python.
[1]: https://en.wikipedia.org/wiki/Pathfinder_Roleplaying_Game
---
gvanrossum: Isn't the whole point that we're trying to solve this without lawyers?
[redacted]: The whole point is that you've been sabotaging Python 2 for years and when someone does what needed to be done from the start, you come up with silly objections.
gvanrossum: OK, bring in the lawyers.
---
Just don’t appropriate a name what’s not yours, and you can maintain all the Python 2.x you want. Pathfinder[1] couldn’t call itself D&D 3.6 – Tauthon or anyone else can’t make things called Python.
[1]: https://en.wikipedia.org/wiki/Pathfinder_Roleplaying_Game
CJefferson probably refers that GvR comment (Though I don't see that strong language here):
""" Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it). """
""" Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it). """
Expand all comments. One is exactly what I quote.
I think you're blowing it out of proportion. Call your project some other name. Say that your interpreter is compatible with Python 2 and that you provide continued support. It will probably be hard to find volunteers because most are moving/have moved to Python 3, but I don't think the threat of lawsuit will scare anyone away except those who want to infringe on PSF's trademarks and in that case...good?
I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers?
What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something.
I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by.
If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques.
And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?
What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something.
I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by.
If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques.
And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?
> I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers?
I 100% agree. I was just responding to the parent post.
I 100% agree. I was just responding to the parent post.
Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever
Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?
> Because you can’t bear the use of parentheses for print, really?
While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares.
I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.
I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.
The original project (Python) is still developed however. If a handoff to some other team occurs and the new maintainers do a bad job this reflects negatively on Python 3.
The motivation for that is probably avoiding what my first thought was; who is going to be the first to offer commercial extension of Python 2 support. That would be worth a lot of money to a lot of companies.
Also I can think of plenty of groups that would like to be able to deploy a differently secured version 2 in their best financial interest.
> Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
Well RedHat annouced a long time ago that RHEL 8 will drop support for Python 2 [0], so at least it appears they also want to leave Python 2 behind. RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Especially, behavior bugs and ports of Python 3 features to python 2 won't be done.
[0] https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...
[1] https://access.redhat.com/support/policy/updates/errata#Main...
Well RedHat annouced a long time ago that RHEL 8 will drop support for Python 2 [0], so at least it appears they also want to leave Python 2 behind. RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Especially, behavior bugs and ports of Python 3 features to python 2 won't be done.
[0] https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...
[1] https://access.redhat.com/support/policy/updates/errata#Main...
> RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me.
Nobody expects new features in python 2.7, so this is basically all the support that people are looking for. RHEL7 will have security maintenance till Jun 2024.
Nobody expects new features in python 2.7, so this is basically all the support that people are looking for. RHEL7 will have security maintenance till Jun 2024.
As we see from the python3 switch motivation, the key support people need is support for their favorite libraries.
In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.
In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.
I wonder how many 3rd party Python2 libraries RHEL ships with?
I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number ready when they answer - transferring you now!"
I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number ready when they answer - transferring you now!"
I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
> I wonder how many 3rd party Python2 libraries RHEL ships with?
Workstation: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Server: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Search for "python"
> I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
If course they don't do fixes for all of pip / PyPI, nobody does/can be reasonably expected to do. They explicitly only cover what they ship (which does includes numpy and scipy, but not pandas). If you can demonstrate an exploit with just "yum install numpy" I'm pretty sure they'll work on it.
Workstation: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Server: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Search for "python"
> I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
If course they don't do fixes for all of pip / PyPI, nobody does/can be reasonably expected to do. They explicitly only cover what they ship (which does includes numpy and scipy, but not pandas). If you can demonstrate an exploit with just "yum install numpy" I'm pretty sure they'll work on it.
Volunteers can of course step up, nothing is preventing anybody. But you shouldn't expect it will happen. Why would anybody voluntarily work on fixing bugs in obsolete software?
People getting paid to work on Python (like at Red Hat) are not considered volunteers.
People getting paid to work on Python (like at Red Hat) are not considered volunteers.
They did step up, even extended the time they were planning to step up by years, but it has to end somewhere.
They say volunteers, so I think they mean just people working for free. In the next section they mention you can probably find support from your vendors or pay a third party to fix it. It then ends with the sentence
> If you need free help from volunteers, look at this help page.
Which links to the help page to learn python, haha. I think the point is that you can fork it or pay someone to fork it, but you won't find anyone else willing to fix your problems for free.
> If you need free help from volunteers, look at this help page.
Which links to the help page to learn python, haha. I think the point is that you can fork it or pay someone to fork it, but you won't find anyone else willing to fix your problems for free.
I think the volunteers here refers the Python core developers and committers. In contrast to cooperation-backed popular modern languages like JS, Python team has few full-time devs maintaining Python. [1] Most of them literally are volunteers.
[1] https://discuss.python.org/t/official-list-of-core-developer...
[1] https://discuss.python.org/t/official-list-of-core-developer...
Not just RedHat - Google and Amazon have LTS that they're providing that will most likely include some flavor of 2.7.
Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time.
Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.
Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time.
Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.
[deleted]
Exactly! I am getting tired of FOSS orgs thinking they can speak for their entire extended community.
`PSF` should be inserted before every occurance of the word volunteer in that page.
`PSF` should be inserted before every occurance of the word volunteer in that page.
They're announcing that the (small group of) people developing the Python2 executable are no longer going to do so after Jan 1st.
In what way does this imply that they're speaking for any "extended community"? Who're you trying to say is being mistaken here as being a "volunteer" but is not a 'PSF volunteer".
I totally get that there is an "extended community" around the Python language(s), including at least module authors, people who write Python frameworks, and people who write code in Python - and _possibly_ including devs at companies who have built products in Python or relying on Python. But it's 100% obvious that the linked article is referring to none of those people.
Who do you think this "FOSS org" was appropriately speaking for?
In what way does this imply that they're speaking for any "extended community"? Who're you trying to say is being mistaken here as being a "volunteer" but is not a 'PSF volunteer".
I totally get that there is an "extended community" around the Python language(s), including at least module authors, people who write Python frameworks, and people who write code in Python - and _possibly_ including devs at companies who have built products in Python or relying on Python. But it's 100% obvious that the linked article is referring to none of those people.
Who do you think this "FOSS org" was appropriately speaking for?
Uh, I think the PSF branding on that page is pretty clear. If you don't want to read a text in the context it's given that's your choice, but don't complain that it becomes ambiguous if read outside of its proper context.
They manage merging though, so it has to be a fork.
Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curated software repository of Python 2 code, starting with the standard lib and some common third-party packages (like Snakefood.) And I'm going to pay technical writers to clean up the documentation.
I don't give a fig about controversy. I just want to keep using Python 2.
I don't give a fig about controversy. I just want to keep using Python 2.
But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly better than 2. With the upcoming 3.8, it seems to be better in every way (including performance!).
I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".
I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".
> By 3.6, it was markedly better than 2.
Better how? Or better at what?
It's likely that our opinions will be different but I've got an open mind and I'm genuinely curious about your experiences and opinion.
(I hated PEP 572 at first but then some comment here on HN made me rethink and change my mind.)
Better how? Or better at what?
It's likely that our opinions will be different but I've got an open mind and I'm genuinely curious about your experiences and opinion.
(I hated PEP 572 at first but then some comment here on HN made me rethink and change my mind.)
f-strings. Enum. Dataclasses. asyncio. Type annotations as code. An explicit separation between bytes and strings. I love each of these and use them regularly. It's not that 2.7 is some abomination I can't stomach, but more that 3.[recent] is all of the things I appreciated about 2.7, plus a million little quality of life and performance enhancements that make it just that much more pleasant to use. I could live without each of those things individually, but would not be willing to give them all up.
I can understand that (it sounds like me, talking about Python 2, eh?)
For me, it’s better at avoiding mistakes. The major one is separating bytestrings from strings, of course. Comparison operators not assigning a default order to different types (1 < "2" is now an error) is great. Division is more explicit. Explicit relative imports save me grief. Similar changes about providing APIs that are harder to misuse throughout the standard library.
That's a good point. There are certainly some warts in 2 that are fixed in 3. Cheers!
Have they even managed to get
Never mind `print(len("ẅ"))`[0] and the like.
0: https://news.ycombinator.com/item?id=20246676
print(b"byte = FF (\xFF)")
Never mind `print(len("ẅ"))`[0] and the like.
0: https://news.ycombinator.com/item?id=20246676
What output do you expect from this ?
If there is a bug, did you file a bug report it ?
If there is a bug, did you file a bug report it ?
I don't your comment a controversial stance. I don't think the "sunsetting python 2" is controversial either.
If there is demand for python2 maintenance, there will be people--like you--working on it and companies selling support for it.
All this announcement is saying that the python community at-large (aka "We are volunteers who make and take care of the Python programming language") is focused on python3 and isn't going to work on python2 any more.
Their position makes sense, even large communities have limited budgets on development capacity, and they want to spend it only on python3. You control your own capacity, so if you want to focus on python2 you'll likely find some like-minded compatriots.
If there is demand for python2 maintenance, there will be people--like you--working on it and companies selling support for it.
All this announcement is saying that the python community at-large (aka "We are volunteers who make and take care of the Python programming language") is focused on python3 and isn't going to work on python2 any more.
Their position makes sense, even large communities have limited budgets on development capacity, and they want to spend it only on python3. You control your own capacity, so if you want to focus on python2 you'll likely find some like-minded compatriots.
Out of curiosity, what is it that you like about Python 2? Not attacking you, just curious. I've never used Python professionally (mostly Ruby and Clojure), so I don't have a horse in this race.
I just realized I didn't answer your actual question, sorry.
> what is it that you like about Python 2?
I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†).
Things that might not seem that big a deal these days were a revelation to me when I started with Python:
- The basic datatypes, list, tuple, and dict, are enough to describe so much of the tasks you need to do.
- Slice notation is so useful, and works on the left-hand side (you can assign to slices) and the elegance (you can reverse a string or list or tuple by oof = foo[::-1].)
- The simple but effective OOP model, "dunderscore" methods, monkey-patching is possible.
- How can I forget! Indentation for blocks! So crazy but it works so well.
- long ints that don't overflow! So nice.
I can go on but really it was the whole thing, the syntax, the semantics, the standard lib. But in my opinion it reach a zenith sometime between 2.4 and 2.7, and even then Python overgrew its ecological niche. (What I mean is that if your project has more than 100,000 lines of Python you're pretty much fucked, but people do that all the time these days. I once worked on a horrible old "lava-flow" enterprisey Python codebase that could have been replaced by Excel but instead employed a gang of programmers. Pure waste.)
†https://en.wikipedia.org/wiki/Amoeba_(operating_system)
> what is it that you like about Python 2?
I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†).
Things that might not seem that big a deal these days were a revelation to me when I started with Python:
- The basic datatypes, list, tuple, and dict, are enough to describe so much of the tasks you need to do.
- Slice notation is so useful, and works on the left-hand side (you can assign to slices) and the elegance (you can reverse a string or list or tuple by oof = foo[::-1].)
- The simple but effective OOP model, "dunderscore" methods, monkey-patching is possible.
- How can I forget! Indentation for blocks! So crazy but it works so well.
- long ints that don't overflow! So nice.
I can go on but really it was the whole thing, the syntax, the semantics, the standard lib. But in my opinion it reach a zenith sometime between 2.4 and 2.7, and even then Python overgrew its ecological niche. (What I mean is that if your project has more than 100,000 lines of Python you're pretty much fucked, but people do that all the time these days. I once worked on a horrible old "lava-flow" enterprisey Python codebase that could have been replaced by Excel but instead employed a gang of programmers. Pure waste.)
†https://en.wikipedia.org/wiki/Amoeba_(operating_system)
While I agree with most of your points, nothing you said really highlights why python2 is better than python3.
(Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way)
(Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way)
> nothing you said really highlights why python2 is better than python3.
I never said that. In fact, I admit that in some ways 3 is better than 2. However, that 2 is static (unchanging) while 3 is being actively changed means that, as time goes on, the cost of using 2 will decrease while the cost of using 3 will increase.
> Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way
I was engaging in a bit of rhetorical flourish there. I know it can be done, but it's not Python's "sweet spot". For large projects, Java or Haskell or even Ada are preferable IMHO. And I say this as a Python partisan.
Cheers!
I never said that. In fact, I admit that in some ways 3 is better than 2. However, that 2 is static (unchanging) while 3 is being actively changed means that, as time goes on, the cost of using 2 will decrease while the cost of using 3 will increase.
> Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way
I was engaging in a bit of rhetorical flourish there. I know it can be done, but it's not Python's "sweet spot". For large projects, Java or Haskell or even Ada are preferable IMHO. And I say this as a Python partisan.
Cheers!
But all of these are in python 3 too?
Yes, but...
Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2.
From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2.
(Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't understand why people think asyncio is cool but ignore Twisted (which is a huge treasure chest of amazing capabilities!))
Since I see 3 as only marginally better than 2, the main difference between them is that 2 is stable and mature while 3 is in flux, and that consideration mashes the cost/benefit ratio waaaay over in favor of 2, IMO.
Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2.
From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2.
(Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't understand why people think asyncio is cool but ignore Twisted (which is a huge treasure chest of amazing capabilities!))
Since I see 3 as only marginally better than 2, the main difference between them is that 2 is stable and mature while 3 is in flux, and that consideration mashes the cost/benefit ratio waaaay over in favor of 2, IMO.
Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase. Porting py2 to py3 is a little more than a few men-month of work. In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
I don't want to come off condescending, I really want to understand your point. But I have no idea what you're trying to say.
Sure, technically py2 and py3 are different languages. So what?
I don't want to come off condescending, I really want to understand your point. But I have no idea what you're trying to say.
Sure, technically py2 and py3 are different languages. So what?
> I don't want to come off condescending, I really want to understand your point.
Same here! Well met.
> But I have no idea what you're trying to say.
Sorry, I'll try again.
> Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase.
Sorry, I was thinking of new projects there.
To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only because I'm maintaining it) so the option of not converting to Python 3 is on the table. In that world, I don't see a compelling reason to adopt Python 3 when Python 2 still exists and is stable. (And FWIW I think some of the py3 folks realize this and that's why they are so eager to "cannibalize" the old for the new, precisely because py3 can't really compete on its own merit against its entrenched incumbent ancestor, eh?)
> In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
You paid a modest but non-zero cost to convert and then what did you get? Was it faster? You didn't convert 2M loc py2 to, say, 1.8M loc py3?
If Python 2 wasn't going away (my premise) would you have converted to Python 3? If so, why?
PyPy is delivering speed improvements, and to me it seems like most if not all of the other language features of py3 can be done in py2 with libraries. Other than compatibility with py3, what was the payoff?
> Sure, technically py2 and py3 are different languages. So what?
Two things: first, the whole reason this mess is happening is IMO because py3 interpreter can't run py2 code. If it could I think the transition would have gone smoothly and been done by now. It wasn't necessarily a bad thing to correct some warts, but it was a deliberate choice to "kill" Python 2 despite the obvious fact that we're going to be stuck with it for years to come (COBOL! FORTRAN! Like Elder Gods, these things don't die.) Really, i don't mind py3! It's the effort to throw py2 onto the funeral pyre while it's still kicking ("I feel happy! I feel happy!") that I find objectionable.
Second, and IMO this is the big deal: py2 is stable while py3 is in flux.
If the language stops changing that means people can work on the tooling and implementation instead. If I was managing a codebase the size of yours I would be much more interested in PySonar (or Cython or Nuitka) than anything that py3 brings to the table. Changes in the language require changes in the tooling (even just your syntax highlighters) so IMO they should be really good to pay for the expense of learning them and supporting them. For example, algebraic data-structures with pattern matching would be a nice addition to Python. (But then, you can do that in a library too!)
In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
Same here! Well met.
> But I have no idea what you're trying to say.
Sorry, I'll try again.
> Porting a python 2 project to Julia/Haskell/Prolog is rewriting the entire codebase.
Sorry, I was thinking of new projects there.
To understand my point keep in mind that I'm assuming a world where Python 2 stays stable and maintained (if only because I'm maintaining it) so the option of not converting to Python 3 is on the table. In that world, I don't see a compelling reason to adopt Python 3 when Python 2 still exists and is stable. (And FWIW I think some of the py3 folks realize this and that's why they are so eager to "cannibalize" the old for the new, precisely because py3 can't really compete on its own merit against its entrenched incumbent ancestor, eh?)
> In my company we have >2 million line of py2 code and we spent a few weeks converting all to py3 (biggest problems being str/unicode and None comparison) and less than a month later our prod runs py3.
You paid a modest but non-zero cost to convert and then what did you get? Was it faster? You didn't convert 2M loc py2 to, say, 1.8M loc py3?
If Python 2 wasn't going away (my premise) would you have converted to Python 3? If so, why?
PyPy is delivering speed improvements, and to me it seems like most if not all of the other language features of py3 can be done in py2 with libraries. Other than compatibility with py3, what was the payoff?
> Sure, technically py2 and py3 are different languages. So what?
Two things: first, the whole reason this mess is happening is IMO because py3 interpreter can't run py2 code. If it could I think the transition would have gone smoothly and been done by now. It wasn't necessarily a bad thing to correct some warts, but it was a deliberate choice to "kill" Python 2 despite the obvious fact that we're going to be stuck with it for years to come (COBOL! FORTRAN! Like Elder Gods, these things don't die.) Really, i don't mind py3! It's the effort to throw py2 onto the funeral pyre while it's still kicking ("I feel happy! I feel happy!") that I find objectionable.
Second, and IMO this is the big deal: py2 is stable while py3 is in flux.
If the language stops changing that means people can work on the tooling and implementation instead. If I was managing a codebase the size of yours I would be much more interested in PySonar (or Cython or Nuitka) than anything that py3 brings to the table. Changes in the language require changes in the tooling (even just your syntax highlighters) so IMO they should be really good to pay for the expense of learning them and supporting them. For example, algebraic data-structures with pattern matching would be a nice addition to Python. (But then, you can do that in a library too!)
In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
Yeah I see your point. To me it's all about trade-offs. A year from now Py3 will have a larger community than whatever replaces Py2. So, investing time to port my code to Py3 was worth it.
> In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
This is a good point, but I disagree. As long as they make future py3 versions backwards compatible, it doesn't affect me if they keep changing py3. To me, it's more important that the world will be operating on py3 as opposed to py2; this is the killer feature of py3.
> In sum, the very fact that py2 is now stable and unchanging is a killer feature (IMO) that differentiates it from py3!
This is a good point, but I disagree. As long as they make future py3 versions backwards compatible, it doesn't affect me if they keep changing py3. To me, it's more important that the world will be operating on py3 as opposed to py2; this is the killer feature of py3.
> A year from now Py3 will have a larger community than whatever replaces Py2.
> the world will be operating on py3 as opposed to py2
You're right, but like I said, for new stuff I'm using Haskell or Prolog or something, not Python {2,3}.
I don't want to advance Python 2 --well, by adding and improving libraries and tooling I do, but not because I plan to make new stuff in py2, rather to make maintenance cheaper-- I just want to prevent it from dying. I'm really only interested in maintenance. Otherwise I would just contribute to Tauthon, but they're modifying the interpreter/language whereas I just want to make the existing thing more solid.
Well met. :-)
> the world will be operating on py3 as opposed to py2
You're right, but like I said, for new stuff I'm using Haskell or Prolog or something, not Python {2,3}.
I don't want to advance Python 2 --well, by adding and improving libraries and tooling I do, but not because I plan to make new stuff in py2, rather to make maintenance cheaper-- I just want to prevent it from dying. I'm really only interested in maintenance. Otherwise I would just contribute to Tauthon, but they're modifying the interpreter/language whereas I just want to make the existing thing more solid.
Well met. :-)
Cheers! Answering you for all three (at the moment) comments asking:
Okay, here goes.
In brief, Python 3 adds work without adding significant (to me) value.
As others have pointed out, you don't get anything from converting an existing project from 2 to 3 other than compatibility with 3. If the Python 3 proponents were to succeed in killing 2 then that becomes compelling, however, since I intend to maintain 2, I don't care about compatibility with 3.
As I have become older my tastes have changed, and nursing an old friend seems easier and more fun than trying to stay up to speed with the new hottness. Especially since it just isn't that hot.
Some details:
First, I see 2 and 3 as different languages. The degree of similarity is not relevant (to my evaluation of which to use) since they are incompatible (in other words, incompatibility is binary not scalar.) Since the abdication of the BDFL it seems to me to be even more appropriate to treat them as separate. I don't know how or why but Guido was good at language design. I feel like he lost his touch somehow, and then he left anyway, so the magical "thing" that made Python so sweet in the first place is gone. (I won't comment on any particular PEPs. It's all been said by others elsewhere.)
I feel that Python 2 hits a sweet spot in language design as compared, not just to other Python versions, but to other languages as well. (If you can't use Lisp or Smalltalk or Prolog at least you have Python.) Python 2.7 is a local optimum with a clear view and steep sides, eh? Python 3 goes crashing down the hill and into the woods...
From this POV the cessation of modification to Python 2 is a boon. It's stable and can only get asymptotically more so over time. It also means that projects like Snakefood that do meta-programming can stabilize because the underlying language is stable. We are only now getting type checking and such, and e.g. MyPy has to expend resources to deal with changes to Python 3 or risk bit-rot.
Python 3 continues to include dubious design decisions that then must be dealt with by other projects/tools. I.e. syntax highlighters have to be modified to deal with "fstrings", etc. It drives a continuous process of change for the sake of change without introducing anything fundamentally new and useful. As a developer, your knowledge is depreciating as you sit there because the language is in flux. With Python 2 the thing you're studying and using is stable. In fact, it's possible that the total amount of code could contract in a stable regime. Especially if you have dev time to work on it (that isn't wasted on pointless new features that then engender additional work to learn and use.)
You can also spare cycles to work on things like improving the standard library documentation, or the packaging/versioning mess, or really anything other than tweaking the language (and, again, making more work for everyone without adding fundamental new facilities.)
Okay, here goes.
In brief, Python 3 adds work without adding significant (to me) value.
As others have pointed out, you don't get anything from converting an existing project from 2 to 3 other than compatibility with 3. If the Python 3 proponents were to succeed in killing 2 then that becomes compelling, however, since I intend to maintain 2, I don't care about compatibility with 3.
As I have become older my tastes have changed, and nursing an old friend seems easier and more fun than trying to stay up to speed with the new hottness. Especially since it just isn't that hot.
Some details:
First, I see 2 and 3 as different languages. The degree of similarity is not relevant (to my evaluation of which to use) since they are incompatible (in other words, incompatibility is binary not scalar.) Since the abdication of the BDFL it seems to me to be even more appropriate to treat them as separate. I don't know how or why but Guido was good at language design. I feel like he lost his touch somehow, and then he left anyway, so the magical "thing" that made Python so sweet in the first place is gone. (I won't comment on any particular PEPs. It's all been said by others elsewhere.)
I feel that Python 2 hits a sweet spot in language design as compared, not just to other Python versions, but to other languages as well. (If you can't use Lisp or Smalltalk or Prolog at least you have Python.) Python 2.7 is a local optimum with a clear view and steep sides, eh? Python 3 goes crashing down the hill and into the woods...
From this POV the cessation of modification to Python 2 is a boon. It's stable and can only get asymptotically more so over time. It also means that projects like Snakefood that do meta-programming can stabilize because the underlying language is stable. We are only now getting type checking and such, and e.g. MyPy has to expend resources to deal with changes to Python 3 or risk bit-rot.
Python 3 continues to include dubious design decisions that then must be dealt with by other projects/tools. I.e. syntax highlighters have to be modified to deal with "fstrings", etc. It drives a continuous process of change for the sake of change without introducing anything fundamentally new and useful. As a developer, your knowledge is depreciating as you sit there because the language is in flux. With Python 2 the thing you're studying and using is stable. In fact, it's possible that the total amount of code could contract in a stable regime. Especially if you have dev time to work on it (that isn't wasted on pointless new features that then engender additional work to learn and use.)
You can also spare cycles to work on things like improving the standard library documentation, or the packaging/versioning mess, or really anything other than tweaking the language (and, again, making more work for everyone without adding fundamental new facilities.)
One very high cost to staying on 2 will be that the pool of 3rd party modules you can draw from will continue to shrink as projects drop support for it. Sure, you can stay on Requests v.whatever, but eventually the SSL certs that it includes will expire, and then you'll have to maintain your own patched Requests with the new certs you want to use. Or eventually someone will find security problems with Django 1.11 LTS, and will be on you to fix them. Also, every Django plugin will have migrated to Python 3, so you won't get to use the new tools for it that everyone else is using.
And at some point, say 10 years from now, you'll reach your breaking point where you'll get tired of maintaining backports for every. little. package. that you want to you use. And when that day comes, then you'll face the even more daunting task of porting your stuff to the new current version of Python.
I'm saying this as one techie to another: don't do this to yourself. Not long term, anyway. If you want to support your own ecosystem for six months or a year as an exercise, sure, I'll be the last one to tell you not to work on a personal project you enjoy. But for Pete's sake, don't engage in this as a long-term project. This isn't how you want to look back on your deathbed and see that you spent a decade.
As a practical matter, I'll say that everyone I've spoken to seems to have the experience that Python 3 seems like a pain in the neck for a very short while as you go through the process of finding all the bugs in your codebase that Python 2 was letting you ignore. But once you've done that, you're not going to want to go back and un-fix them even if you decided to stick with Python 2, and if you've already gone through that work, why not enjoy the new language features and 3rd party packages now available to you?
And at some point, say 10 years from now, you'll reach your breaking point where you'll get tired of maintaining backports for every. little. package. that you want to you use. And when that day comes, then you'll face the even more daunting task of porting your stuff to the new current version of Python.
I'm saying this as one techie to another: don't do this to yourself. Not long term, anyway. If you want to support your own ecosystem for six months or a year as an exercise, sure, I'll be the last one to tell you not to work on a personal project you enjoy. But for Pete's sake, don't engage in this as a long-term project. This isn't how you want to look back on your deathbed and see that you spent a decade.
As a practical matter, I'll say that everyone I've spoken to seems to have the experience that Python 3 seems like a pain in the neck for a very short while as you go through the process of finding all the bugs in your codebase that Python 2 was letting you ignore. But once you've done that, you're not going to want to go back and un-fix them even if you decided to stick with Python 2, and if you've already gone through that work, why not enjoy the new language features and 3rd party packages now available to you?
I get what you're saying and I think you're pretty much describing what it will be like. But honestly, I'm kind of looking forward to it. To me it's like maintaining a favorite model train set or something. A labor of love.
(Going forward I'm more likely to use Julia, Haskell or Prolog than Python 3 for new code.)
(Going forward I'm more likely to use Julia, Haskell or Prolog than Python 3 for new code.)
I am interested in your opinion on an idea.
What do you think it would have happened if python 3 included a python 2 interpreter (as a command line flag or even a library) so that everyone could switch to python 3.
I understand they where almost incompatible as runtimes so it would have doubled size but it would make easier to propagate the diffusion of python 3.
Do you think a project such as Bladders would have been still possible had this happened?
What do you think it would have happened if python 3 included a python 2 interpreter (as a command line flag or even a library) so that everyone could switch to python 3.
I understand they where almost incompatible as runtimes so it would have doubled size but it would make easier to propagate the diffusion of python 3.
Do you think a project such as Bladders would have been still possible had this happened?
FWIW, I think that if 3 had the ability to run 2 code (on a per-module basis, say) the whole mess would have been avoided.
Honestly, I'm not so much a Python 3 hater, as a lover of stability. To me the idea of Python 2 being stable for the foreseeable future is exciting because it means I can concentrate on improving the tooling (e.g. tools like PySonar and Snakefood and such. I would add MyPy but of course they will be chasing Python 3 now.)
> Do you think a project such as Bladders would have been still possible had this happened?
Maybe... You can run C code from decades ago. That's pretty awesome. I guess it would depend (in this hypothetical) on whether the 3 interpreter was ever going to drop support for 2 code.
Honestly, I'm not so much a Python 3 hater, as a lover of stability. To me the idea of Python 2 being stable for the foreseeable future is exciting because it means I can concentrate on improving the tooling (e.g. tools like PySonar and Snakefood and such. I would add MyPy but of course they will be chasing Python 3 now.)
> Do you think a project such as Bladders would have been still possible had this happened?
Maybe... You can run C code from decades ago. That's pretty awesome. I guess it would depend (in this hypothetical) on whether the 3 interpreter was ever going to drop support for 2 code.
> I just want to keep using Python 2.
Honestly curious as to why you would prefer to stay behind?
Honestly curious as to why you would prefer to stay behind?
Anyone with a large python 2 codebase is going to want to stay behind if they could.
People still run old FORTRAN from 20 years ago in production. I'm sure some old COBOL code is out there. The reality of not wanting to re-write working code is somewhat real.
People still run old FORTRAN from 20 years ago in production. I'm sure some old COBOL code is out there. The reality of not wanting to re-write working code is somewhat real.
This is such a good analogy, and really highlights the point that python 2 stalwarts look at organizations hiring for FORTRAN and COBOL today, and say to themselves, "Yes, this is the kind of organization I want to build." An organization that will either (most likely) be completely irrelevant in 10 years time or have to pay a massive premium salary for any engineer that can maintain their systems.
Not only are there scientific disciplines where modern Fortran is still dominant, but there isn't much of a salary premium for working there.
And people said what you said about it 10 years ago. And 20 years ago. And 30 years ago.
When those folks want to do scripting, they mostly use Python. And they mostly use Py3, from what I can see.
And people said what you said about it 10 years ago. And 20 years ago. And 30 years ago.
When those folks want to do scripting, they mostly use Python. And they mostly use Py3, from what I can see.
Are people routinely still purposefully writing new code in 20 year old versions of FORTRAN, or just maintaining existing stuff?
it's not on purpose, it's out of necessity. For example, a company has a huge COBOL code base. It plans to migrate to say, python. After 2 years of analysis, and some failures, they realize how much their organisation is driven by the software. So they decide to change their business processses. Another two years of analysis. Now they start rewriting again. After one year, they realize the consluting company responsible for the rewrite is screwing them, they stop the effort. New management comes in : "we need to put more resources in marketing, so we put all IT efforts on hold for two years". Now marketing needs data about its customers, so they ask the IT team to build some reports. This implies coding new stuff in COBOL, after 5+ years...
That's what I'm in right now :-)
That's what I'm in right now :-)
Back when my startup had a Fortran compiler as one of its products, most of our customers were writing new code in modern Fortran, and modernizing old code. The folks who were just running what they had without updating it probably were using g77 or another free compiler.
You've got no contact details on your profile....
I suppose there's no point in putting this off any further, eh?
Project repo: https://git.sr.ht/~sforman/Bladders Mailing list: https://lists.sr.ht/~sforman/bladders-announce Subscribe: mailto:~sforman/[email protected]
At this moment it is total vaporware. I should have some time this week to clone the Python 2 code and set up a virtual server farm to compile it and run test suite on some different platforms, as a start. (Or I just remembered srht has a "builds" tool that might be just the ticket.)
Project repo: https://git.sr.ht/~sforman/Bladders Mailing list: https://lists.sr.ht/~sforman/bladders-announce Subscribe: mailto:~sforman/[email protected]
At this moment it is total vaporware. I should have some time this week to clone the Python 2 code and set up a virtual server farm to compile it and run test suite on some different platforms, as a start. (Or I just remembered srht has a "builds" tool that might be just the ticket.)
Some shared hosting providers are still offering Python 2.6 as their main offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version.
[1] https://www.hostgator.com/help/article/what-software-and-pro...
[1] https://www.hostgator.com/help/article/what-software-and-pro...
I was Googling “HostGator Python 3” and found you said the same thing last year on HN:
https://news.ycombinator.com/item?id=16808998
We knew in April 2014 that Python 2 was EOL in 2020.
https://news.ycombinator.com/item?id=16808998
We knew in April 2014 that Python 2 was EOL in 2020.
Yes, I was hoping for some progress at HostGator so I could get rid of the last Python 2.x I have running. But I can't, yet.
I bet there is still some shitty hosting company somewhere offering Perl4 CGI script hosting.
Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)
Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)
No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts to run on my pastebin, https://perl.bot/ . In this case it's not incompetence but insanity.
How did you get the older Perls working? (I've tried and failed to get them to build on Ubuntu.)
Manually patching the source in a few places, most of the time it's just adding a header file or two since some of them predate ANSI C and the standardized header files. The other things have to do with adding -DHAS_... to force them to know that opendir and friends are actually present, so that make install will actually work.
Any chance you could release the patches?
Nice!
Much respect. That’s retro-cool.
Much respect. That’s retro-cool.
That's also why I added COBOL, that and to test some ideas on how to handle compiled languages on it. The backend service supports multiple files but I haven't finished the web side of things to handle that (I have a strange requirement to make it work without javascript).
If you're after stupid suggestions, would it be "breaking your personal rules" to use only enough Javascript to allow just enough of a transpiled version of the in-browser Java runtime to let '90s vintage Java Applets run? Or maybe Flash?
(And no, I'm 100% not offering to do any of the work required to make that come true... ;-) )
(And no, I'm 100% not offering to do any of the work required to make that come true... ;-) )
I'd be willing to try something like that, but both flash and java applets are horrendously complex. The javascript restriction is because it's mostly used by us perl developers on irc and there's a few disgruntled greybeards that will actually use it via lynx or links. Closest thing for flash is shumway, https://mozilla.github.io/shumway/ which might be possible to make work but it's still got a lot of compatibility issues from what i hear.
Until it becomes a vector for malware. Shouldn't be laughed at, since it's going to waste person hours in the future.
PHP-style shared hosting is not where Python users are. The shared-hosting story for Python has always been pretty bad, with rare exceptions (webfaction, before godaddy swallowed it). Python users are overwhelmingly on VPS and PaaS, where versions can be easily upgraded. Any PaaS provider without Python 3.6+ at this point is not worth paying for.
HostGator moves slow as frozen molasses but they do when they have to. Case-in-point, they rolled out Let's Encrypt support like the week that Chrome starting marking HTTP pages insecure.
As they are on CentOS 6 it would be impractical to switch to another version as default as Python is used by the system, however they do have 2.7 installed.
With Software Collections[1], using more recent Python versions on CentOS 6 is trivial. Bad excuse.
[1]: https://softwarecollections.org/
[1]: https://softwarecollections.org/
CentOS 6 itself is EOL late next year.
> Shared hosting providers
Like Google App Engine lol. GAE Standard Environment doesn't support Python 3.
Like Google App Engine lol. GAE Standard Environment doesn't support Python 3.
This is incorrect. https://cloud.google.com/appengine/docs/standard/python3/
You're technically correct in that GAE standard offers python 3, but it's not the same as their python 2 offering.
Python 2 is part of the first generation runtimes, python 3 is part of the second generation runtimes. They are not out of the box compatible, even if your python code works on 2 and 3. The first generation runtime included many APIs that are simply just not available in the second gen (you need to build them yourself). See link for more info.
https://cloud.google.com/appengine/docs/standard/runtimes
Python 2 is part of the first generation runtimes, python 3 is part of the second generation runtimes. They are not out of the box compatible, even if your python code works on 2 and 3. The first generation runtime included many APIs that are simply just not available in the second gen (you need to build them yourself). See link for more info.
https://cloud.google.com/appengine/docs/standard/runtimes
This is true for Go as well.
GAE has been a favorite of mine for years, but now they seem hellbent on ruining it, and I don't understand why ='(
(On the plus side, other things are improving and Run looks good)
GAE has been a favorite of mine for years, but now they seem hellbent on ruining it, and I don't understand why ='(
(On the plus side, other things are improving and Run looks good)
I have numerous apps on their original standard environment. I'd have to rebuild huge parts of every single one of them for this completely different environment.
The original standard environment has a free tier and doesn't require billing and as such is great for everyone who can't or don't want to enter their credit card information.
While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it.
As an aside, a few weeks ago I interviewed at one of the top 5 investment banks for a software engineering role to maintain one of their main trading systems, written entirely in Python 2. My first question was what their plans were in porting what they called "one of the worlds largest Python 2 code bases," and it was "on the roadmap".
Surely the Python core team are aware that teams like this exist in some of the largest companies in the world, and I assume they've had at least some level of dialogue with companies like this to say "we're super serious this time, we're about to stop support for Python 2", or something along those lines?
Maybe it's a blessing in disguise that I was rejected?
As an aside, a few weeks ago I interviewed at one of the top 5 investment banks for a software engineering role to maintain one of their main trading systems, written entirely in Python 2. My first question was what their plans were in porting what they called "one of the worlds largest Python 2 code bases," and it was "on the roadmap".
Surely the Python core team are aware that teams like this exist in some of the largest companies in the world, and I assume they've had at least some level of dialogue with companies like this to say "we're super serious this time, we're about to stop support for Python 2", or something along those lines?
Maybe it's a blessing in disguise that I was rejected?
> I'm still surprised that it's taken this long to finally close support
That's because the Python community is too nice.
When Ruby or node broke compat, they just said "move or die". People moved.
When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair.
They got an extension of 5 more years.
People still complained !
Hell, famous authors resented python 3 for years, refusing publicly to update their book.
On the other hand, the PSF had a very small budget, only few tiny donations and contributions by people or big companies that were saying they couldn't migrate that their lines of code. The same code that were making them a living, from a 25 years old amazing tech given to them for free.
My take on this is that if you are doing an open source project with a lot of volunteer work, don't be too nice. People have a tendency to abuse it. Save yourself trouble, and balance respect with users and convenience for you.
That's because the Python community is too nice.
When Ruby or node broke compat, they just said "move or die". People moved.
When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair.
They got an extension of 5 more years.
People still complained !
Hell, famous authors resented python 3 for years, refusing publicly to update their book.
On the other hand, the PSF had a very small budget, only few tiny donations and contributions by people or big companies that were saying they couldn't migrate that their lines of code. The same code that were making them a living, from a 25 years old amazing tech given to them for free.
My take on this is that if you are doing an open source project with a lot of volunteer work, don't be too nice. People have a tendency to abuse it. Save yourself trouble, and balance respect with users and convenience for you.
Something about the "too nice" thing rubs me the wrong way. You gotta respect the people who develop the software. At the same time, the way people are deemed "complainers" reeks of contempt for the users. Yes, the users sometimes take your free work for granted. But you offered it. If you don't like the expectations that users assume are attached to it, you should say so upfront so they can become entangled with Ruby instead.
I don't think I disagree with your point in practice. Maybe in some details. I just don't think that not being credible in your plan to drop support on a given date is necessarily such a "nice" thing to do. You could say it's a "weak" thing to do. It doesn't help people prioritize the move and eventually hurts people by putting them into a jam on the day finally comes here. I think the ideal thing would be to break compatibility piece by piece, assuming it's really necessary, but be _understanding_ about it. Tell people "we understand that this is inconvenient for a certain number of people but have to cut it off at some place", not "stop complaining about free stuff".
I don't think I disagree with your point in practice. Maybe in some details. I just don't think that not being credible in your plan to drop support on a given date is necessarily such a "nice" thing to do. You could say it's a "weak" thing to do. It doesn't help people prioritize the move and eventually hurts people by putting them into a jam on the day finally comes here. I think the ideal thing would be to break compatibility piece by piece, assuming it's really necessary, but be _understanding_ about it. Tell people "we understand that this is inconvenient for a certain number of people but have to cut it off at some place", not "stop complaining about free stuff".
> When Ruby or node broke compat, they just said "move or die". People moved.
Unless I'm missing something, this is a pretty disingenuous comparison. Ruby and Node breaking changes have been fairly small, Python 3 was anything but.
Unless I'm missing something, this is a pretty disingenuous comparison. Ruby and Node breaking changes have been fairly small, Python 3 was anything but.
You can count your blessings. I think I know what company you’re talking about, and as far as I know they have no inclination to ever port anything. It’s the sort of company with enough money to pay to have their own runtime, simply because it’s organisationally easier to throw money at “maintenance” once established, than it is to do a big port or rewrite. Legacy support is a well-paying job, if depressing.
That's good to know, because I was a bit sad at the rejection, despite a chat with their tech lead setting off a few alarm bells.
Well, the largest companies in the world don't have to rely on volunteers, they can pay for continued support.
I've never worked for a company of that scale, so I don't know how hard it'll be to find legacy developers, but I imagine it'll take at least several years to port a public-facing system to Python 3, if they were to start now.
If they start in the next few years, I imagine it'll be much harder to find ready and willing Python 2 developers with the experience to navigate such a big code-base? They could hire consultants, but I imagine the future hiring cost will also be astronomical.
If they start in the next few years, I imagine it'll be much harder to find ready and willing Python 2 developers with the experience to navigate such a big code-base? They could hire consultants, but I imagine the future hiring cost will also be astronomical.
Well Python 3 came out in 2008, this date is known since 2014. If they start in the next few years, yes you'd expect it to be expensive.
But distribution vendors like Red Hat and Ubuntu have Python 2 in long term support distributions that they will give support for a few more years, so it is possible to use those. And after that they offer more years of support to paying customers. It's not necessary to hire programmers to do this for the companies needing support themselves.
But distribution vendors like Red Hat and Ubuntu have Python 2 in long term support distributions that they will give support for a few more years, so it is possible to use those. And after that they offer more years of support to paying customers. It's not necessary to hire programmers to do this for the companies needing support themselves.
> I'm still surprised that it's taken this long to finally close support. ... I interviewed at one of the top 5 investment banks for a software engineering ... My first question was what their plans were in porting ... it was "on the roadmap".
> Surely the Python core team are aware that teams like this exist in some of the largest companies in the world
Why would you assume they considered their users? Maybe they went purely for some abstract purity with tenuous benefits and didn't actually speak to their stakeholders. Remember, the "D" in BDFL stands for "dictator".
> Surely the Python core team are aware that teams like this exist in some of the largest companies in the world
Why would you assume they considered their users? Maybe they went purely for some abstract purity with tenuous benefits and didn't actually speak to their stakeholders. Remember, the "D" in BDFL stands for "dictator".
JP Morgan, isn't it?
The platform can already run in python 3. It's possible that the team you interviewed with wasn't aware of that.
Like all big companies, personal experience varies with the team and the part of the company you're in.
The platform can already run in python 3. It's possible that the team you interviewed with wasn't aware of that.
Like all big companies, personal experience varies with the team and the part of the company you're in.
Nope, not JP Morgan, although I did interview with them too and they talked about some of their Python systems and how they were currently in the process of porting to Python 3.
I won't name names, but they're also in the top ten and based in America.
I won't name names, but they're also in the top ten and based in America.
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?
Rule of thumb is that no version == python2, either because it pre-dates 3 or because the developer's concept of python is "what happens when I type python at the shell" so it's still 2. It's often a big red flag about quality; competent Python developers find it natural to state py3 support upfront (or lack thereof) because they know it matters.
Eh. Disagree. For small projects on Github that are actively maintained, it's more likely to be Python 3 and not Python 2 if not explicitly stated. Newer developers for newer projects just don't care about Python 2.
I think your point about competency is the best point.
Recently though, I have been running into more and more projects that don't specify the version and are built using Python 3. I also used your rule of thumb, so seeing this was kind of surprising. Wonder if it's just the mentality shift that Python3 == Default?
Recently though, I have been running into more and more projects that don't specify the version and are built using Python 3. I also used your rule of thumb, so seeing this was kind of surprising. Wonder if it's just the mentality shift that Python3 == Default?
If they are using PyPI, the project should be specifying which versions it supports in either setup.cfg or setup.py[1].
For example, I decided to only support Python3 going forward. I've had person once open a PR to add python2 support, but I politely declined[2]. As such, PyPI shows that only 3.5+ is supported[3].
[1] https://github.com/RPGillespie6/fastcov/blob/master/setup.cf...
[2] https://github.com/RPGillespie6/fastcov/pull/11
[3] https://pypi.org/project/fastcov/
For example, I decided to only support Python3 going forward. I've had person once open a PR to add python2 support, but I politely declined[2]. As such, PyPI shows that only 3.5+ is supported[3].
[1] https://github.com/RPGillespie6/fastcov/blob/master/setup.cf...
[2] https://github.com/RPGillespie6/fastcov/pull/11
[3] https://pypi.org/project/fastcov/
If not otherwise specified, I just look for a `print` command and see if its formatted as
print 'my string' indicating Python 2
or print('my string') indicating Python 3.
Yea, that's what I've come around to. Thanks for confirming that's a good path.
It's usually specified in setup.py.
Recently I ran into a Python script on GitHub that I couldn't get to run on 2 _or_ 3.
Both errors were familiar from earlier cases of trying to run with the wrong Python version, but I have no idea how the code managed to do that for both, and frankly it wasn't worth the effort to look into.
Both errors were familiar from earlier cases of trying to run with the wrong Python version, but I have no idea how the code managed to do that for both, and frankly it wasn't worth the effort to look into.
The transition to python 3 from 2 was rough I’ll give you that. But companies and maintainers have had years and years to either fork and port or altogether rewrite their code for python 3 — the only python that matters.
I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken to move your codebase to python 3.
I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken to move your codebase to python 3.
From my experience, large codebase refactorings are almost never a priority until the deadline is just right there. 10 years for many companies mean the last 6 months, when everyone else has already done a lot of work on the same problems as you will encounter, lots of issues have been already solved, and you can probably find people with the python 3 skill. And last but not least, you will find approvals from management side "this year's the end of support, it must be done, otherwise we are out of security patches". So, essentially yes, they gave a lot of time for enterprise companies to let others do the dirty work :)
That's true. I worked at an enterprisey shop that delayed upgrading from Java 6 before its EOL. By the time they started, the EOL date had passed a few months prior and the upgrade itself was a 1.5 year effort. Some orgs can be pushed, others have to be shoved.
I long for the day when typing "python" into a shell will bring up a python 3 prompt
Switch to Arch Linux and live the dream. It has had python3 as /usr/bin/python since 2010.
https://www.archlinux.org/news/python-is-now-python-3/
https://www.archlinux.org/news/python-is-now-python-3/
Also Gentoo since mid-2018.
Although their package management requires manually specifying the minimum accepted Python version for every single package, so they have thousands of packages that would run just fine on Python 3.7 but no one has the time to manually check and label them as such. So their default is still 3.6 and using 3.7 as your default version is not well supported.
I wish someone told me Gentoo is a non-starter before I wasted an afternoon installing it.
While we're on the topic, it's pretty stupid how PEP 394, the one that says "python should point to python2.7", gives its reasoning as "because all Linux distros except Arch do it this way" and then all the distros say "python should be python2 because the PEP says so" for the next 9 (maybe more) years. How is anything ever supposed to change?
Although their package management requires manually specifying the minimum accepted Python version for every single package, so they have thousands of packages that would run just fine on Python 3.7 but no one has the time to manually check and label them as such. So their default is still 3.6 and using 3.7 as your default version is not well supported.
I wish someone told me Gentoo is a non-starter before I wasted an afternoon installing it.
While we're on the topic, it's pretty stupid how PEP 394, the one that says "python should point to python2.7", gives its reasoning as "because all Linux distros except Arch do it this way" and then all the distros say "python should be python2 because the PEP says so" for the next 9 (maybe more) years. How is anything ever supposed to change?
My mint 19.2 installation does the same. To run a python 2 script I have to run my conda python 2.7 install now.
Is Manjaro included in that?
Edit: Yes Manjaro has default Python3 too. :)
Edit: Yes Manjaro has default Python3 too. :)
Windows 10 now offer you to install Python 3 if you do this.
And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk!
How many more decades must we wait??
How many more decades must we wait??
Hopefully never.
If I have a modern C compiler, I can still run most C code from 30 years ago.
When I have a Rust 2030 compiler, I'll still be able to run Rust 2015.
But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.
If I have a modern C compiler, I can still run most C code from 30 years ago.
When I have a Rust 2030 compiler, I'll still be able to run Rust 2015.
But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.
As soon as calibre and mercurial finish their ports to python 3, python 2 will vanish from my Arch install. The day approaches!
I ended up just aliasing "python" to Python3 and "python2" to Python2. Hasn't broken much yet in MacOS
It does on a Windows vm if you checked the add to path checkbox.
sudo ln -sf /usr/bin/python3 /usr/bin/python
Or use a Linux distribution like Arch that has python symlinked to python3 by default.
Or use a Linux distribution like Arch that has python symlinked to python3 by default.
Or maybe just alias it so you don't break anything.
Install pyenv and live your dream.
So they are sun-setting it 12 years after having introduced its replacement.
I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.
I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.
.Net 5 will be reuniting the brands (Though based on .net core). So the Core brand will be discontinued. Read more about it here:
https://devblogs.microsoft.com/dotnet/net-core-is-the-future...
They're changing the branding ... AGAIN?!
The brand is one thing but your project will still be incompatible.
"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 now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration.
In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary.
In contrast, Python has become a bit fractured, with a number of notable well-discussed but unaddressed loose ends in Python3: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases.
The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental.
Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
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 now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration.
In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary.
In contrast, Python has become a bit fractured, with a number of notable well-discussed but unaddressed loose ends in Python3: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases.
The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental.
Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
> 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 now as they're reading it.
If people haven't found reason in the last ten years, then they aren't about to be convinced today. All the arguments for and against have already been widely discussed, and that the EOL of Python2 is here should come as a shock to exactly no one.
There's no reason to re-hash over and over what is already out there.
If people haven't found reason in the last ten years, then they aren't about to be convinced today. All the arguments for and against have already been widely discussed, and that the EOL of Python2 is here should come as a shock to exactly no one.
There's no reason to re-hash over and over what is already out there.
The tone is excessive and over-the-top because it's the last of numerous documents over the years saying essentialy the same thing. And yeah, they are probably sick of supporting Python 2 because a few vocal users still complain a decade after the writing is on the wall.
There are tons of incentives to upgrade, but unfortunately very few to none can be considered killer features, and thus are harder to show off in a concise reminder about the sunset.
You have to give it a try and actually use Python 3 features to realize how much this improves your life as a developer.
Python 3 isn't perfect, but especially with later versions, it's a hell of an improvement over Python 2.
There are tons of incentives to upgrade, but unfortunately very few to none can be considered killer features, and thus are harder to show off in a concise reminder about the sunset.
You have to give it a try and actually use Python 3 features to realize how much this improves your life as a developer.
Python 3 isn't perfect, but especially with later versions, it's a hell of an improvement over Python 2.
Did we read the same document? It seems fine and a perfectly normal explanation of what’s going on and why, like any software with a defined lifecycle would have.
I guess it depends what lens you are reading it through. If you're used to reading documents from open source projects it seems perfectly normal. If you're used reading documents from Oracle and SAP explaining changes to their long term support contract, then this will sound completely alien.
If they had put “Pay x USD to continue using python 2 till 2020” in the document, I bet it would have been less alien to oracle customers [1].
[1] https://www.businessinsider.com/oracle-customer-explains-aud...
[1] https://www.businessinsider.com/oracle-customer-explains-aud...
I for one am glad that my favorite FOSS projects do not talk like sterile Oracle PR drones, nor act like them.
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.
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.
Yes, those people are arrogant and/or entitled, but you know darn well that's not the arrogance GP was talking about.
It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
As choppaface said,
> Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided. I love Python and I love GvR, but he stumbled badly here IMO (not as badly as Perl 6, but that's small comfort) by trying, in effect, to cannibalize 2 for 3. I don't enjoy saying this.
I've met GvR briefly and he didn't seem arrogant at all to me. But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
As choppaface said,
> Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided. I love Python and I love GvR, but he stumbled badly here IMO (not as badly as Perl 6, but that's small comfort) by trying, in effect, to cannibalize 2 for 3. I don't enjoy saying this.
I've met GvR briefly and he didn't seem arrogant at all to me. But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?
That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?
First,
> why don't you cough up the cash?
I am.
Second,
> "decide to no longer volunteer their own time."
If that's all they were saying I would STFU.
They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are still using it.
> why don't you cough up the cash?
I am.
Second,
> "decide to no longer volunteer their own time."
If that's all they were saying I would STFU.
They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are still using it.
Making them use a name other than python is hardly any great hardship. Mozilla maintains their trademark too and nobody whines to hard about that. Just call it "boa" or something. Firefox->Icecat.
> Making them use a name other than python is hardly any great hardship.
It wasn't. (And Tauthon is arguably a really cool name.)
But it does indicate that they want Python 2 dead.
> Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
Like I said, if people were just fading out of Python 2 that wouldn't make me call them arrogant, it's when they insist that other people have to ditch Python 2 that I start to feel like there's some arrogance there.
Like I said in a another comment, the only thing you get from switching to Python 3 is Python 3 compatibility. If Python 2 remains viable (which it will) there's much less incentive to use 3.
Python 2 isn't broken or bad or anything, it's just not Python 3. We aren't being urged to switch because 2 is (so much) worse than 3 but because it's a viable competitor to it.
It wasn't. (And Tauthon is arguably a really cool name.)
But it does indicate that they want Python 2 dead.
> Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
Like I said, if people were just fading out of Python 2 that wouldn't make me call them arrogant, it's when they insist that other people have to ditch Python 2 that I start to feel like there's some arrogance there.
Like I said in a another comment, the only thing you get from switching to Python 3 is Python 3 compatibility. If Python 2 remains viable (which it will) there's much less incentive to use 3.
Python 2 isn't broken or bad or anything, it's just not Python 3. We aren't being urged to switch because 2 is (so much) worse than 3 but because it's a viable competitor to it.
> But it does indicate that they want Python 2 dead.
Being less uncharitable, it indicates they want to avoid brand dilution (which is wholly reasonable.)
Being less uncharitable, it indicates they want to avoid brand dilution (which is wholly reasonable.)
Okay, but then what do they get by avoiding brand dilution?
Look, I'm not really interested in proving that so-and-so is arrogant or not.
It's pretty clear to me that some people have some animosity to continued use of Python 2, and I find some of the language and attitudes smack of arrogance. I'm arrogant, and it takes one to know one, eh?
But I don't have a magic arrogance-o-meter so really what are we arguing about? Our feels?
Look, I'm not really interested in proving that so-and-so is arrogant or not.
It's pretty clear to me that some people have some animosity to continued use of Python 2, and I find some of the language and attitudes smack of arrogance. I'm arrogant, and it takes one to know one, eh?
But I don't have a magic arrogance-o-meter so really what are we arguing about? Our feels?
Arguably, your reference upthread to the Perl5/6 problems makes it a more than reasonable request that the trademark "Python" doesn't get confused in the minds of users by awkwardly referring to 2 different and incompatible languages, however tightly they were related a decade ago.
Perhaps you could argue that the Python3 language could have changed it's name and "left" the trademark and reputation behind for some other random people to take over. But a stronger argument would be that the reputation Python has earned over the last two decades "belongs" to the ongoing team who built and supported it for way longer as version 2.X than they needed to and who've now been releasing it as V3 for over a decade.
If "people are still using" Python2, nobody is going to stop them. Nobody it deleting all the copies of the source code to Python2.7 or revoking any of the rights the granted when it was released:
"PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version" (from: https://github.com/python/cpython/blob/2.7/LICENSE )
It you're uptight because the PSF owns and protects the trademark to the name "Python" where used in relation to a programming language _that they wrote and gave away and granted you extensive rights to do whatever you damn well please with their source code_ - that's a totally unreasonable expectation on your part.
Spend two decades building your own reputation for intelligent and responsive language design and stewardship, then walk away from all that reputation by allowing random people to piggyback off it, then get back to me and tell me how that's actually how shot should work... Guido and his team have put the hard yards in. They've given you pretty much free reign to do whatever you like with their source code. They are not only under no obligation to allow you to call what you do with that "Python", but they arguably have a responsibility to ensure that people who expect a historical level of stewardship and "benevolent dictatorship" of the language called "Python" are not mislead by people other than them using that name to continue to promote old and discarded technology and design decisions with any assumption that those new people deserve any of the historical reputation that "Python" implies.
Get over the "Wah! I can't use the name Python! I'm being oppressed!!!" childishness. I, for one, do not want _you_ specifically, and people like you in general, to fraudulently trade in the reputation that the Python trademark would bestow on your work if you were allowed to call it "Python".
Perhaps you could argue that the Python3 language could have changed it's name and "left" the trademark and reputation behind for some other random people to take over. But a stronger argument would be that the reputation Python has earned over the last two decades "belongs" to the ongoing team who built and supported it for way longer as version 2.X than they needed to and who've now been releasing it as V3 for over a decade.
If "people are still using" Python2, nobody is going to stop them. Nobody it deleting all the copies of the source code to Python2.7 or revoking any of the rights the granted when it was released:
"PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version" (from: https://github.com/python/cpython/blob/2.7/LICENSE )
It you're uptight because the PSF owns and protects the trademark to the name "Python" where used in relation to a programming language _that they wrote and gave away and granted you extensive rights to do whatever you damn well please with their source code_ - that's a totally unreasonable expectation on your part.
Spend two decades building your own reputation for intelligent and responsive language design and stewardship, then walk away from all that reputation by allowing random people to piggyback off it, then get back to me and tell me how that's actually how shot should work... Guido and his team have put the hard yards in. They've given you pretty much free reign to do whatever you like with their source code. They are not only under no obligation to allow you to call what you do with that "Python", but they arguably have a responsibility to ensure that people who expect a historical level of stewardship and "benevolent dictatorship" of the language called "Python" are not mislead by people other than them using that name to continue to promote old and discarded technology and design decisions with any assumption that those new people deserve any of the historical reputation that "Python" implies.
Get over the "Wah! I can't use the name Python! I'm being oppressed!!!" childishness. I, for one, do not want _you_ specifically, and people like you in general, to fraudulently trade in the reputation that the Python trademark would bestow on your work if you were allowed to call it "Python".
> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
No one is doing that. Python 2 is available, open-source software. The Python core team discontinuing development isn't grabbing it out of anyone's hands. Open source projects whose core teams have discontinued them in favor of an incompatible (either technologically or by licensing) alternative, or abandoned them altogether (or just not maintained them in a way that pleased the community), have often had maintenance picked up by alternative maintainers, who have often had to use alternative names for the independent continuation project. Nothing is taken out of anyone's hands by this.
> If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided.
And we all saw how well starting with that goal worked for Perl 6.
> But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
No one has that attitude (except maybe employers, but that's more about a desire to continue to get paid for using Python 2 than merely to continue to use it.) You are perfectly free to continue using Python 2 until the Earth is swallowed up by the Sun and no one will stop you, or even really care.
No one is doing that. Python 2 is available, open-source software. The Python core team discontinuing development isn't grabbing it out of anyone's hands. Open source projects whose core teams have discontinued them in favor of an incompatible (either technologically or by licensing) alternative, or abandoned them altogether (or just not maintained them in a way that pleased the community), have often had maintenance picked up by alternative maintainers, who have often had to use alternative names for the independent continuation project. Nothing is taken out of anyone's hands by this.
> If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided.
And we all saw how well starting with that goal worked for Perl 6.
> But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
No one has that attitude (except maybe employers, but that's more about a desire to continue to get paid for using Python 2 than merely to continue to use it.) You are perfectly free to continue using Python 2 until the Earth is swallowed up by the Sun and no one will stop you, or even really care.
In what way is "we are no longer going to provide any of our volunteer time to support Python2" even _vaguely_ able to be characterised as "grabbing it out of the hands of people still using it"???
Here: https://github.com/python/cpython/tree/2.7
Join the other 11.5k people who've forked it on Github, and an unknown number of people who've cloned it without playing Github's high-school popularity contest...
Nobody is ever going to take anything Python2 related away from you.
There's a lot of talk here about "arrogance", all from people upset that some other people have decided not to do any _more_ free volunteer work on a thing they've been trying to get people to upgrade from for 3/6/12 years depending on how you count it. Those people complaining about "arrogance" are putting words into the mouths of the people who've done so much free work for them over th=e last 20 years, accusing them of saying "fuck you" and of "grabbing things out of the hands of people" and of "cannibalising" the code they wrote 15-20 years ago while providing newer better code (which happens to not suit some people who're not prepared for whatever reason to update their own code).
GvR is _not_ the one seeming arrogant in this thread...
(And didn't the last line in my comment you replied to make it abundantly clear I knew exactly what arrogance the OP was incorrectly claiming, and what the actual arrogance on display was?)
Here: https://github.com/python/cpython/tree/2.7
Join the other 11.5k people who've forked it on Github, and an unknown number of people who've cloned it without playing Github's high-school popularity contest...
Nobody is ever going to take anything Python2 related away from you.
There's a lot of talk here about "arrogance", all from people upset that some other people have decided not to do any _more_ free volunteer work on a thing they've been trying to get people to upgrade from for 3/6/12 years depending on how you count it. Those people complaining about "arrogance" are putting words into the mouths of the people who've done so much free work for them over th=e last 20 years, accusing them of saying "fuck you" and of "grabbing things out of the hands of people" and of "cannibalising" the code they wrote 15-20 years ago while providing newer better code (which happens to not suit some people who're not prepared for whatever reason to update their own code).
GvR is _not_ the one seeming arrogant in this thread...
(And didn't the last line in my comment you replied to make it abundantly clear I knew exactly what arrogance the OP was incorrectly claiming, and what the actual arrogance on display was?)
> The tone in this document is excessive and over-the-top.
No, the quoted passage is exactly correct. Many major tools have dropped Python 2 support, and others have put that on their timeline. If you continue to stick with Python 2, you will lose out on the ability to use an increasing number of current tools, because the community is moving on. Relaying that fact isn't arrogant.
No, the quoted passage is exactly correct. Many major tools have dropped Python 2 support, and others have put that on their timeline. If you continue to stick with Python 2, you will lose out on the ability to use an increasing number of current tools, because the community is moving on. Relaying that fact isn't arrogant.
> There were often clear incentives to upgrade [...] In contrast, Python has become a bit fractured
A bit? This is an incentive.
A bit? This is an incentive.
Don't quite unterstand the downvotes. Meanwhile the language and more important the entire infrastructure is affected: python vs. python3 switches pollute virtual environments, deployment, whole systems scripting code, bindings, derived code and more. This is not 'a bit'. Ending this situation is, as already mentioned, a (big) incentive.
When 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.
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.
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.
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.
GCC deprecates and removes support for target architectures and various other flags with each major release. If you care about receiving security updates for your application, you have to upgrade the compiler, and to upgrade the compiler you may have to make changes to your application and/or physical hardware. Very few of the architectures that were available 30 years ago are still supported by any maintained compiler today.
Similarly, developers are not forced to upgrade to python 3 any more than they are forced to upgrade to GCC 4, in that they can keep using their old tools but they're SOL on maintenance if they don't meet the requirements of the new versions.
So, either your team chose really well 30 years ago, is actively working on an horribly insecure application, or has invested some modicum of effort periodically over the last 30 years to maintain support with the compiler (unlike the developers complaining about Python 3's upgrade window).
Similarly, developers are not forced to upgrade to python 3 any more than they are forced to upgrade to GCC 4, in that they can keep using their old tools but they're SOL on maintenance if they don't meet the requirements of the new versions.
So, either your team chose really well 30 years ago, is actively working on an horribly insecure application, or has invested some modicum of effort periodically over the last 30 years to maintain support with the compiler (unlike the developers complaining about Python 3's upgrade window).
We are moving CPUs, we aren't still using amigas and 386s :) but old C code, broadly speaking, still compiles in gcc 8.
Python 2 code, broadly speaking, still runs in Python 3. It's the not-broad parts that are the problem...
Yeah, sorry buddy, but that's just not how modern software dev works. Platforms change, code gets outdated, and whilst older platforms "work", they're likely not taking advantage of all the features that have been added to platforms since that time.
It's much easier/better when you are forced into dealing with the change. At least people can laugh at how annoyed others get when they cry "but you broke everything!".
It's called progress. Get with the times or get outdated.
It's much easier/better when you are forced into dealing with the change. At least people can laugh at how annoyed others get when they cry "but you broke everything!".
It's called progress. Get with the times or get outdated.
You say that, but if I boot a Linux kernel, load X, open a terminal and run bash/vim/general terminal tools, almost everything I'm running is probably using a combination of C89/C99/C++98/C++03, all of which are still well support by GCC and clang.
For the first 8-10 Years, migration was not possible for most people for several reasons, shrinking the timescale to 2-3 years for the majority.
Though you could have done most of the work ahead of time.
Python 2 was nowhere near ready for EOL in 2008; making it not very credible.
TBF, Perl 5 is not a language with a stated EOL. "Perl 6" is no longer even considered a successor, and if reason prevails, the language-formerly-known-as-Perl=6 will get a fresh name and cut loose, releasing the "one true Perl" from under its shadow.
> I want to be able to run my software in 10 years
You can! Just buy 10 year old hardware, and run a 10 year old operating system. That's how banks, schools, governments, etc are running 40 year old software.
You can! Just buy 10 year old hardware, and run a 10 year old operating system. That's how banks, schools, governments, etc are running 40 year old software.
On the topic of large companies still using Python 2, I would love to hear about Splunk's upgrade plans. They have the following[1] on their SDK page about upgrading, but my understanding is their entire platform is still on Python 2.
I've upgraded a number of projects at my work to Python 3 this year, but nothing that 2-3 developers couldn't do in a few weeks. Can only imagine the headache of migrating something the size of Splunk.
[1]: https://dev.splunk.com/view/SP-CAAAFG7
I've upgraded a number of projects at my work to Python 3 this year, but nothing that 2-3 developers couldn't do in a few weeks. Can only imagine the headache of migrating something the size of Splunk.
[1]: https://dev.splunk.com/view/SP-CAAAFG7
Granted I don't work at Splunk anymore, but did recently. They were definitely working hard on migrating everything to python3, and if I remember, they had a planned roll out where python2/python3 would co-exist.
However, if you've been using the python SDK for Splunk - its been supporting python3 for a few years already (https://github.com/splunk/splunk-sdk-python/commit/4503db961...)
See this blog post: https://www.splunk.com/blog/2019/07/01/admins-and-developers...
And this helpful doc: https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Mi...
However, if you've been using the python SDK for Splunk - its been supporting python3 for a few years already (https://github.com/splunk/splunk-sdk-python/commit/4503db961...)
See this blog post: https://www.splunk.com/blog/2019/07/01/admins-and-developers...
And this helpful doc: https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Mi...
Really appreciate those links!
I honestly had no idea the SDK has supported Python 3 for this long. Granted, I haven't worked with it since 2015, but still surprised I missed that. Glad to hear they are making such good progress.
I honestly had no idea the SDK has supported Python 3 for this long. Granted, I haven't worked with it since 2015, but still surprised I missed that. Glad to hear they are making such good progress.
I work at Splunk - we're in the process of upgrading to Python 3 support. It's about as much of a nightmare as you would expect with a 15 year old codebase with [essentially] plugin support (by way of external Python code in Apps). The good news is, we've entered Beta!
Sad to see them forging ahead on their plans to drop Python 2, and it would have been nice of them to point out that other volunteers will provide security fixes for Python 2 compatible runtimes.
I've switched to Tauthon [1] for over a year now and have been quite pleased. Consider the switch yourself rather than rewriting your code.
[1] https://github.com/naftaliharris/tauthon
I've switched to Tauthon [1] for over a year now and have been quite pleased. Consider the switch yourself rather than rewriting your code.
[1] https://github.com/naftaliharris/tauthon
In your opinion, is there any particular reason to start a new project, or is this disappointment for lack of legacy support?
A popular library that has unfortunately not transitioned to Python 3 yet is rospy (which is part of the larger ROS ecosystem for robotics). It is the last framework that prevents me to fully embrace Python 3 for my everyday work. I sincerely hope the robotics community will eventually port rospy (and other ROS-related libraries) to Python 3.
I am, however, very happy to see that ROS2 (the next iteration of ROS) uses Python 3 by default.
I am, however, very happy to see that ROS2 (the next iteration of ROS) uses Python 3 by default.
I'm in the same boat. It bothers me that my only option will be to rewrite in Python 3. Unless they provide a very clear migration path, I'm far more likely to just remove ROS entirely, unfortunately.
The otherwise amazing Windows service ninite.com is still offering Python 2.7.16 and is not offering Python 3.
There was a discussion on HN about this a few years ago, but I am curious to see what does ninite.com plan to do now?
There was a discussion on HN about this a few years ago, but I am curious to see what does ninite.com plan to do now?
I'm happy this finally happened, even though I've been clinging to Python 2.7 for quite some time.
I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7.
In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you plan to use Python 3.5+. There wasn't any app level changes that had to be done other than optionally removing some dual import try/excepts to work for both 2.x and 3.x. The biggest pain point was remembering to use print with parenthesis but I've been doing that for a while now so it's a non-issue.
This was based on a decently sized Flask app with tens of top level dependencies and many thousands of lines of code.
If someone wants to see how this upgrade process looked in real time, I recorded that and put it up on Youtube[1] the other week. The video also covers some gotchas you might encounter during the upgrade process (especially if you're running in production and deal with sessions).
[0]: https://buildasaasappwithflask.com/
[1]: https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-...
I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7.
In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you plan to use Python 3.5+. There wasn't any app level changes that had to be done other than optionally removing some dual import try/excepts to work for both 2.x and 3.x. The biggest pain point was remembering to use print with parenthesis but I've been doing that for a while now so it's a non-issue.
This was based on a decently sized Flask app with tens of top level dependencies and many thousands of lines of code.
If someone wants to see how this upgrade process looked in real time, I recorded that and put it up on Youtube[1] the other week. The video also covers some gotchas you might encounter during the upgrade process (especially if you're running in production and deal with sessions).
[0]: https://buildasaasappwithflask.com/
[1]: https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-...
pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!
> pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!
Yes but check the changelog for pytest.
Version 5.x.x is only available for Python 3.5+. They dropped support for 2.7 and <= 3.4, unless you fall back to the 4.6 series.
Yes but check the changelog for pytest.
Version 5.x.x is only available for Python 3.5+. They dropped support for 2.7 and <= 3.4, unless you fall back to the 4.6 series.
Great stuff. But what about alternative python interpreters that have been lagging behind? Jython is 2.7.1 and IronPython is 2.7.9
They are effectively both dead or moribund. Jython has had a py3 experimental branch for ages but the entire project is basically starved of money and effort.
To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
Does that view include PyPy? I'm not deep into Python (aside from the Monty kind) but it seems to be maintained and makes performance claims.
PyPy is a python-focused project that builds a python-focused runtime. My comment was more about projects trying to retrofit Python on top of runtimes that were built for very different languages, typically because of some constraint that has now disappeared.
The GIL constraint has not.
If the GIL is so important to you that you're willing to suffer the pain of running on another VM with a much-reduced ecosystem, while at the same time having requirements so complex that PyPy cannot meet them, maybe Python is just not the right tool for the project.
Moved the goalposts.
I am sorry that you see statements of fact and acceptance of reality as an adversarial debate.
IronPython is a dead project at this point…
Well, he's... he's, ah... probably pining for the fjords.
For the JVM, there has been some work on new interpreters for Python 3 based on GraalVM. Unfortunately none seem production-ready at the moment.
What I hate about this document is part of a bigger problem I see with the Python community.
It's written like a hate letter with a passive aggressive tone of finger pointing towards users of Python as the source of the never-ending Python 2-3 split. It says, between the lines: "YOU are part of the problem, stop using Python 2. We don't care about YOU anymore. Stop using Python 2".
I can think of ten other different ways to be more constructive and, generally, nice.
It's written like a hate letter with a passive aggressive tone of finger pointing towards users of Python as the source of the never-ending Python 2-3 split. It says, between the lines: "YOU are part of the problem, stop using Python 2. We don't care about YOU anymore. Stop using Python 2".
I can think of ten other different ways to be more constructive and, generally, nice.
It's been 10+ years, they're just being a matter of fact.
I still see companies working with Python2 but I am happy for this announcement - as it will make moving to Python 3 faster.
I don't believe this is a new announcement, the date has been known for years.
This would never have been such an unpleasant issue if Python 3 hadn't broken backward compatibility in very annoying ways; one of the more inexcusable examples was removing the print statement, a convenient piece of syntax that dates to antiquity, and which could have peacefully coexisted with the print() function in Python 3.
Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p
Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p
This should have been done in 2010. People will procrastinate 12 years if you give them a 12 years deadline.
My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that kind of subtle defaults that I think slowed the transition. I didn't want to change the system Python.
In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time.
I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.
I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.
Actually you _can_ disable SIP and replace use/bin/Python, but that is a Very Bad Idea.
Apple will (eventually) entirely remove Python:
https://developer.apple.com/documentation/macos_release_note...
Hopefully they will fix the shitty keyboard before that happens, so I can finally replace my old Macbook Pro.
Scripting Language Runtimes
Deprecations
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7.
https://developer.apple.com/documentation/macos_release_note...
Hopefully they will fix the shitty keyboard before that happens, so I can finally replace my old Macbook Pro.
Scripting Language Runtimes
Deprecations
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7.
I hope the Raspberry Pi community really switches to Python3 soon.
I've looked at the PiStorms stuff MindSensors (Lego Mindstorms compatible). Unfortunately it all seems to be just Python2 based.
Looking at all the code it seems you're always basically running your own event loop (infinite while True: loop). I think it'd be really awesome to utilize Python 3's asyncio package to write more event driven programs.
Writing code in asyncio is basically a different paradigm. It's not like Golang where you can write a function and not care if someone is calling it synchronously or starting a goroutine with it. With Python asyncio it seems for every good library out there someone has a create an asyncio version of it. For instance "requests" vs. "aiohttp".
So, while embracing Python 3 still wouldn't get me what I ultimately want, it's a first step in the right direction.
I've looked at the PiStorms stuff MindSensors (Lego Mindstorms compatible). Unfortunately it all seems to be just Python2 based.
Looking at all the code it seems you're always basically running your own event loop (infinite while True: loop). I think it'd be really awesome to utilize Python 3's asyncio package to write more event driven programs.
Writing code in asyncio is basically a different paradigm. It's not like Golang where you can write a function and not care if someone is calling it synchronously or starting a goroutine with it. With Python asyncio it seems for every good library out there someone has a create an asyncio version of it. For instance "requests" vs. "aiohttp".
So, while embracing Python 3 still wouldn't get me what I ultimately want, it's a first step in the right direction.
> For instance "requests" vs. "aiohttp".
"asks" implements a requests-like interface over asyncio/trio.
"asks" implements a requests-like interface over asyncio/trio.
And now remind yourself that there are self driving cars out there and autonomous digging equipment that is based on ROS, which doesn't have any plan or intent to move to python 3.
Fun stuff...
Fun stuff...
ROS 1.1 (next release) will target Python3 only.
https://discourse.ros.org/t/versioning-roadmap-moveit-1-0-re...
https://discourse.ros.org/t/versioning-roadmap-moveit-1-0-re...
Thats not true, you're referencing the ROS wiki page of the MoveIt! Planning package, which has nothing to do with ROS other than using it.
Widespread Python3 adoption is planned for ROS 2 which has been vaporware for the last 3 years.
Well the ROS wiki says otherwise: http://wiki.ros.org/UsingPython3
Yeah but the general consensus for the core stuff seems to be "we'll do that with 2.0", which at this point seems to
materialize since forever aka. vaporware...
Is ROS used in production for this? I've only seen it used for prototyping.
Yeah,
Built Robotics[1] apparently does, at least according to their hiring page.
And I think Audi is using it for their self driving cars...
https://www.builtrobotics.com/
And I think Audi is using it for their self driving cars...
https://www.builtrobotics.com/
I mean hiring page doesn't mean they actually use it in the product. You can use ROS for designing the system, but in terms of performance it has issues if you try to use it in an embedded context. I still kind of doubt they have it running in their product.
Makeshift solutions last the longest, I'd highly doubt that they run 2 messaging systems side by side, thats just unrealistic for a startup. Especially considering that ROS is very invasive with it's MSG format and build tooling.
People spend more time whining about the transition than it would take to do the actual transition. Sigh.
The battle has not over yet.
RHEL 8 has Python 2.7 in their Application Streams.
So looks like Red Hat will provide security updates until Jun 2024
https://access.redhat.com/node/4079021
There was some mention somewhere that RH will support the python 2.7 appstream for RHEL 8 as long as RHEL 7.x is supported. Which coincidentally is June 2024, so, yeah.
It's always good to see such big movements but as a truly peaceful p2 dev, I'm not even considering to upgrade my projects unless it'd cost me labor not to upgrade.
I mean this announcement is not a threat, it's a warning. After a certain point there is diminishing returns on not upgrading.
Given that you said "projects", why don't you try an experiment of porting one of the smaller projects and have and evaluate how much of a hassle it is? I am willing to bet you will figure out is not that complicated at all.
I would have loved to upgrade sooner, but I work in technical art and all our tools are version-locked by native python extensions and QT5's compat. See discussion at: https://vfxplatform.com/
I predict Maya devs (and, by extension, game engine vendors. like Epic/Unreal, who version-lock to Maya's version) will stay on 2x well past 2020 by making their own platform-compat patches.
I predict Maya devs (and, by extension, game engine vendors. like Epic/Unreal, who version-lock to Maya's version) will stay on 2x well past 2020 by making their own platform-compat patches.
One of the more annoying aspects of the Python 2 to 3 transition is with large movie / video production houses, eg Pixar. Their USD library only supports Python 2, since they aren't interested in supporting Python 3. I wonder if that will change next year.
The "industry standard" platform is only just getting around to switching to Python 3: https://vfxplatform.com
The "industry standard" platform is only just getting around to switching to Python 3: https://vfxplatform.com
That's why Python receives a bad name, and for a good reason. Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java. The same thing about C and C++, these languages introduce new features as times evolve, but they still allow users to retain their investment in old code. This is not the case with Python. Because of some bad design decisions, they inflicted pain on their users for more than a decade to force them into choosing one version or another. And now they are deprecating a version of the language that is still used by millions of people, causing again more trouble. Why in the world they need to deprecate this code when there are millions of people who use it all day long? I still see lots of code continuing to be written in Python 2, and all this code will have to be rewritten just because of some bad design and implementation decisions of a few people developing this language.
>Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java
This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively developed and Oracle will not even sell support for java 1, let alone release security updates.
This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively developed and Oracle will not even sell support for java 1, let alone release security updates.
No
Typically version N+1 of a language compiles version N, N-1, all the way back to version 1. Usually, when this isn't the case, the incompatible areas of a language were either marked experimental, or obscure use cases that very few people use.
Today's Java compiler will compile source code written for Java 1.
The issue with Python 2 and Python 3 is extremely unusual in a language.
Typically version N+1 of a language compiles version N, N-1, all the way back to version 1. Usually, when this isn't the case, the incompatible areas of a language were either marked experimental, or obscure use cases that very few people use.
Today's Java compiler will compile source code written for Java 1.
The issue with Python 2 and Python 3 is extremely unusual in a language.
I might be misunderstanding your comment, but I have encountered source code that is not forward compatible in java. Some examples below...
Incompatibilities between JDK 7 and JDK 6: https://www.oracle.com/technetwork/java/javase/compatibility...
Incompatibilities between JDK 8 and JDK 7: https://www.oracle.com/technetwork/java/javase/8-compatibili...
An exerpt from the Compatibility Guide for JDK 8 [1]:
>In general, the source compatibility policy is to avoid introducing source code incompatibilities. However, implementation of some Java SE 8 features required changes that could cause code that compiled with Java SE 7 to fail to compile with Java SE 8. See Incompatibilities between Java SE 8 and Java SE 7 and Incompatibilities between JDK 8 and JDK 7 for information.
There are also a plethora of deprecated and removed APIs throughout Java's history.
[1]:https://www.oracle.com/technetwork/java/javase/8-compatibili...
Incompatibilities between JDK 7 and JDK 6: https://www.oracle.com/technetwork/java/javase/compatibility...
Incompatibilities between JDK 8 and JDK 7: https://www.oracle.com/technetwork/java/javase/8-compatibili...
An exerpt from the Compatibility Guide for JDK 8 [1]:
>In general, the source compatibility policy is to avoid introducing source code incompatibilities. However, implementation of some Java SE 8 features required changes that could cause code that compiled with Java SE 7 to fail to compile with Java SE 8. See Incompatibilities between Java SE 8 and Java SE 7 and Incompatibilities between JDK 8 and JDK 7 for information.
There are also a plethora of deprecated and removed APIs throughout Java's history.
[1]:https://www.oracle.com/technetwork/java/javase/8-compatibili...
Thanks for proving my point.
The incompatible areas that you explain amount to bug fixes and obscure areas of the language. They aren't anything like Python 2 vs 3.
The incompatible areas that you explain amount to bug fixes and obscure areas of the language. They aren't anything like Python 2 vs 3.
After seeing the months- to years-long process that enterprises have undertaken when migrating from one JDK version to another because of these "obscure areas", I have little empathy for anyone delaying a python upgrade they've been given a 10+ year window for. Ruby 1.8 to 1.9 was similarly painful to python.
Exactly. People who think that the Python situation is normal don't have any experience with programming languages. C compilers can compile code that was written 40 years ago. Java can do this all the way to version 1. Python requires you to make an effort to chose the version of language you want, otherwise the tooling system won't let you run that code. It is true that they later created tools to help with this process, but the mere existence of such hackery shows only how poorly conceived the idea really was.
If you think that’s true, you haven’t supported enough legacy C code. Yes, the core language hasn’t changed much - like Python - but the includes, libraries, operating system APIs, etc. have - and that’s before you learn how vague compatibility was for code written before sometime in the 90s. Similarly, I’ve seen large Java projects take years to upgrade while comparability issues are sorted out.
In all cases, the real problem is technical debt management: rather than attacking people who gave you something for free, ask whether it’s possible that the experience has more to do with procrastinating on upgrades until many large changes have to be made at once with inadequate test automation.
In all cases, the real problem is technical debt management: rather than attacking people who gave you something for free, ask whether it’s possible that the experience has more to do with procrastinating on upgrades until many large changes have to be made at once with inadequate test automation.
I'm on the outside looking in but practically speaking, why couldn't I "just use Python 3" then for everything?
Python 2 and 3 are different compiler/interpreters. Python 2 code might run on a Python 3 interpreter, but probably not. When you run your python2 code, you can specify that it is to run on the Python 2 compiler/interpreter. The Python 2 compiler/interpreter will continue to run and thus be able to run python2 code for a very long time.
Ubuntu 18.04 example:
Ubuntu 18.04 example:
$ python --version
Python 2.7.15+
$ python2 --version
Python 2.7.15+
$ python3 --version
Python 3.6.8
$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 9 Apr 16 2018 /usr/bin/python -> python2.7How much did you personally contribute to the success of Python, or any of the dozens of FREE software tools you probably use daily (and perhaps hundreds or thousands, once you factor in transient dependencies), to justify such criticism for their work?
Some of their “bad” designs were made decades ago, before it was even clear where the industry was going. Take Unicode: lots of bets were made on that, and arguably Windows got it way wrong. Sure their APIs are still “compatible” but what is that worth, when strings are an inconsistent mess that to this day require developer hacks? And that’s an OS people pay for, written by competent engineers as well.
If you don’t like your free software, please feel free not to use it anymore.
Some of their “bad” designs were made decades ago, before it was even clear where the industry was going. Take Unicode: lots of bets were made on that, and arguably Windows got it way wrong. Sure their APIs are still “compatible” but what is that worth, when strings are an inconsistent mess that to this day require developer hacks? And that’s an OS people pay for, written by competent engineers as well.
If you don’t like your free software, please feel free not to use it anymore.
No one is saying you can no longer use Python 2. The community is just saying that if you do, you're more or less on your own. Python 2 won't magically stop working on Jan 1 2020.
In the world of commercial computing, nobody can work on a language that is not supported. Essentially what they are saying is that companies need to scramble to port their code to Python 3 or risk running their systems in an unsupported language. This will in practice be just another hurdle that users need to go through to continue using Python.
Those companies can pay someone else to provide support for Python 2.
Last I checked, macOS doesn't include python3, just python2. I wrote a handy tool for our team, but nobody uses it because they don't have python3. Now I have to play sysadmin on dozens of machines.
A few had 3.5, but I used 3.6.
What can be done to make this easier? I.e. why isn't python3 pre-installed by now? esp 3.6 or 3.7?
A few had 3.5, but I used 3.6.
What can be done to make this easier? I.e. why isn't python3 pre-installed by now? esp 3.6 or 3.7?
Because Apple is notorious for using outdated libraries in macOS, like OpenGL. They included Python, but it was never a real focus to stay up to date since it was primarily to support legacy software.
With that said, Apple will not be including Python (or the other scripting languages like Ruby or Perl) at all starting with Catalina.
With that said, Apple will not be including Python (or the other scripting languages like Ruby or Perl) at all starting with Catalina.
Honestly it's about time. I've been annoyed at having to maintain two versions of python.
Really difficult to track are issues caused by things like the map function now returning an iterator object. I.e. the content of the iterator is empty on second use.
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = map(lambda v: v + 1, [1, 2, 3])
>>> list(x)
[2, 3, 4]
>>> list(x)
[]I don't think the main problem is to change the version of Python, but the version of all the related libraries, which many of them depend on 2.7 version.
I know many of the big ones are already on 3.x for a long time, but I wonder how long will it take to replace and upgrade all the small ones if it did not happen already...
BTW I don't know how necessary was to break compatibility between 2.7 and 3, the pain of this transition comes from that decision
I know many of the big ones are already on 3.x for a long time, but I wonder how long will it take to replace and upgrade all the small ones if it did not happen already...
BTW I don't know how necessary was to break compatibility between 2.7 and 3, the pain of this transition comes from that decision
Any major library that hasn't moved to Python 3 by now isn't going to on their own accord. Either that means they won't, or that the sunsetting will kick them into gear (or get their users to kick them into gear).
It should be pointed out that Python 2 will continue to be used, and be usable. It just won't get new security upgrades or features. I do not know, but I doubt if there will be a feature or security flaw come up soon that "forces" existing python 2-only libraries to update
It should be pointed out that Python 2 will continue to be used, and be usable. It just won't get new security upgrades or features. I do not know, but I doubt if there will be a feature or security flaw come up soon that "forces" existing python 2-only libraries to update
Every now and then a language like no other pops up: it's use is unusual and unusually long. Various biblical languages come to mind: Latin, Church Slavonic, Hebrew at one point. These languages are feature complete, and the fact that they didn't change was their main appeal.
I've always thought Python 2 might be headed for the languages. Which is fine, it's great to have a programming equivalent of Latin.
I've always thought Python 2 might be headed for the languages. Which is fine, it's great to have a programming equivalent of Latin.
... I'm sorry, but wouldn't the Latin equivalent be C... given Python is written in it, and most languages syntax is born from it.
Python is more like the English language... it's borrowed a bunch of stuff from many different languages and isn't even compatible with itself ;) (2 vs 3).
I mean, this is assuming with thing spoken languages are even at all similar to programming languages... which I don't think they are.
Python is more like the English language... it's borrowed a bunch of stuff from many different languages and isn't even compatible with itself ;) (2 vs 3).
I mean, this is assuming with thing spoken languages are even at all similar to programming languages... which I don't think they are.
Funnily enough, Latin became relatievely stable because people stopped using it outside the Church. After the fall of the Rome it quickly transformed into French, Spanish, Italian etc.
Latin is getting new words all the time. The Vatican is the official maintainer. Sometimes it gets grammar tweaks too.
Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
> Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
Just to clarify further, modern Hebrew is mostly backwards compatible with biblical Hebrew, it's not an entirely new language. It was mostly updated in terms of vocabulary that was necessary for the modern era, plus some spelling/grammar changes.
Modern Hebrew speakers are able to read biblical Hebrew almost completely, though there are some differences (think of English speakers reading Shakespeare - though even less difference than that.)
Just to clarify further, modern Hebrew is mostly backwards compatible with biblical Hebrew, it's not an entirely new language. It was mostly updated in terms of vocabulary that was necessary for the modern era, plus some spelling/grammar changes.
Modern Hebrew speakers are able to read biblical Hebrew almost completely, though there are some differences (think of English speakers reading Shakespeare - though even less difference than that.)
Sounds like Python 3 (Modern Hebrew) vs Python 2 (Biblical Hebrew), no? Anyone who can read Python 3 should barely struggle at all with Python 2. Anyone who can read Python 2 will see a few tweaks in the grammar / functionality (“vocabulary” in this analogy), but mostly straight forward.
I guess I didn't go deep enough with the analogy.
Python 2 sees new code all the time too. It's not dead! That's the whole point, it can simultaneously not see any new changes but still be used by those who value the absence of change.
Python 2 sees new code all the time too. It's not dead! That's the whole point, it can simultaneously not see any new changes but still be used by those who value the absence of change.
This is good news for new users to python when getting books that start with an argument for using 2 or 3 and then the book trying to be in both.
Does someone know if there is a way to compile python programs to some sort of static binary?
I have a GPS watch and some old Python 2 script to export the data (found it online (unmaintained) a few years ago).
However, when Python 2 will be sunsetted I am a bit worried that Linux distributions will stop packaging the dependencies of said script, but I would like to keep using it until the watch breaks.
I have a GPS watch and some old Python 2 script to export the data (found it online (unmaintained) a few years ago).
However, when Python 2 will be sunsetted I am a bit worried that Linux distributions will stop packaging the dependencies of said script, but I would like to keep using it until the watch breaks.
You could give py2exe a try. They have an old python2 version that might work for you.
https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/
https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/
Thanks, sounds like what I am looking for, but sadly it doesn't seem to be available for Linux :-/
Which script are you talking about? Can you send me a link to it or or something? Email is in my profile.
I would be interested to see if I can update to python 3.
I would be interested to see if I can update to python 3.
Docker could do what you want, though it's definitely not an efficient solution.
Nice idea. Might be a good start to learn to build my own docker images.
At last...
I wonder if there is an interesting lesson learned here for future language maintainers.
One of the reasons for the 14 year deprecation windows (imho) is that the language maintainers didn't have control over much of the core platform libraries/ in everyday use. This created a lot of community angst against the upgrade path.
One of the reasons for the 14 year deprecation windows (imho) is that the language maintainers didn't have control over much of the core platform libraries/ in everyday use. This created a lot of community angst against the upgrade path.
Wow. I still found some inadequacies with six, such as support for bytes/b, datetime (timestamp) and SimpleHttpServer
Overall, didn't have too many issues with the conversion but this stuff is going to hit some companies harder than others. I can tell that it's worth the migration, end this blood fest once and for all.
Overall, didn't have too many issues with the conversion but this stuff is going to hit some companies harder than others. I can tell that it's worth the migration, end this blood fest once and for all.
I think the sunsetting is very premature. Python 3 became a stable and viable alternative only since 3.6.1 (look at the evolution of async/await before that for example). Giving it 2 years is definitely not enough for enterprise (unless their focus is startup, tinkerers and data scientists)
I mean, arguably they’ve been telling you too move for far longer. So it seems reasonable to sunset it after 10 years.
So migrate a large production codebase to unstable API? With dependencies not yet migrated?
Loads of open source and commercial projects have already made the switch to python 3 years ago. If all of them could do it, so could your org. No excuses, you've made your bed, etc.
Much of the work could have been done ahead of time.
That being said - python 3 was released in 2008. A 12 year transition is pretty respectable.
Python 2 to 3 comments can be boiled down to three constituencies:
1. Native Python 3 Developers: It's great over here, what's the problem?
2. Python 2 Developers Migrating a Small App: It barely took me any time, you Python 2 developers are lazy and inhibiting progress!
3. Python 2 Developers Migrating a Large App: Ugh.
1. Native Python 3 Developers: It's great over here, what's the problem?
2. Python 2 Developers Migrating a Small App: It barely took me any time, you Python 2 developers are lazy and inhibiting progress!
3. Python 2 Developers Migrating a Large App: Ugh.
11 years to make relatively small breaking changes. That's not a good sign for future breaking changes.
It seems everyday that history moves on, anyways this is a historic day and I applaud the principal's for making a difficult decision. I wish them all the best.
I've only used python for scripts and such and pandas for data-analysis at my last job.
I've only used python for scripts and such and pandas for data-analysis at my last job.
> We need to sunset Python 2 so we can help Python users.
We need to <specific goal> so we can <universal statement>. That statement is boilerplate manipulative garbage.. its ok to speak this way because you agree with the goal ?
We need to <specific goal> so we can <universal statement>. That statement is boilerplate manipulative garbage.. its ok to speak this way because you agree with the goal ?
It’s certainly a meaningless statement, but I don’t think it’s manipulating anyone
Maybe Python 2 can go away soon. Also, modern Python 3 support isn't even close to 100% either.
https://pyreadiness.org/3.7/
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.
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.
When will OS vendors stop defaulting `python` to Python 2? It seems like an unnecessary trap that pushed new developers to an out of date version. Even Ubuntu 19.04 defaults to Python 2.7.16
I checked my system (Archlinux) a few weeks ago and the only things with Python2 dependencies where the Gimp and Calibre. Kudos to everyone who has worked on the migration over all these years.
I'll never forgive the loss of the convenient print statement and easy string handling. So much for "practicality beats purity." At least most of the other new stuff is good.
Is there even a plan to transition the chromium code base to python3?
This issue is marked as wont-fix
https://bugs.chromium.org/p/chromium/issues/detail?id=61357
Here is another issue which looks more recent and hopeful https://bugs.chromium.org/p/chromium/issues/detail?id=942720
Here is another issue which looks more recent and hopeful https://bugs.chromium.org/p/chromium/issues/detail?id=942720
The fact that ubuntu's (and by extension, most WSL installs') default python is python 2 is crazy, and definitely not helping the situation.
Finally. The transition is not hard, just time consuming, just split the work among the team and force everyone to make a little progress each day.
Thank God. It's been really annoying having to add parenthesis to all the print statements when I accidently download a python 2 script.
I've found that the 2to3 script will do this. The real pain is finding everything that now has to be bytes instead of string.
which is why python3 is dead to me.
They took too long and that’s one of the factors making the sunset harder today. They should have ripped the band-aid 10 years ago.
Python
Two distinct languages that happen to have the same name
Two distinct languages that happen to have the same name
Python 2 was the language through which I was introduced to programming. My first love in this field !!
Adios
python 2 will continue to run on production systems for at least another decade, thanks to centos6 and making it basically impossible to upgrade to python3 as the main python binary on the system without completely breaking everything.
I'm curious which PyPI packages are preventing you from updating to Python3?
Guessing some Python 2 users rebel and fork to provide security patches.
Maybe now the Android AOSP build scripts will be updated to python3....
If it weren't a forced update, I personally have not found much in Python 3 that is a benefit over 2. It seems the unicode support is the big change, but I just use ASCII encoding, so unicode doesn't matter to me.
> but I just use ASCII encoding
No you don't! :D
No you don't! :D
Search for 'default' https://docs.python.org/2/howto/unicode.html
Thought you meant 3, not 2.
Finally, print is no longer a reserved keyword!
Time for python 4. Python 3 to sunset in 2025!
I still want to keep using Python 2.
sounds like they should probably sunset Python 3 instead
Protip: 2to3
Finally.
rising
We are volunteers who make and take care of a Python2 fork with backwards-compatible Python3 features. That means we will keep on improving it without breaking your code base or forcing you to hire the language creator and spend more than 3 years porting your code to Python3, with no actual business benefits.
https://github.com/naftaliharris/tauthon/
https://github.com/naftaliharris/tauthon/
CJefferson(3)
Given we'll be at Python 3.8 next month, I can't help but wonder about Python 4. When it will happen, and how long.
All indications are that we'll see 3.10 before 4 is considered.
I think it would probably be ok to start thinking about it in a year or two from the py2 sunset. It will be a minor update anyway, it's just a PR exercise that can be done whenever people think it would be more effective.
I think it would probably be ok to start thinking about it in a year or two from the py2 sunset. It will be a minor update anyway, it's just a PR exercise that can be done whenever people think it would be more effective.
New features planned for python 4.0:
http://charlesleifer.com/blog/new-features-planned-for-pytho...
http://charlesleifer.com/blog/new-features-planned-for-pytho...
You missed a /s there.
I dont think python 4 will be what you think it will. Most likely it will just be the next version of 3, not a game changing upgrade.
Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
Just don’t let your technical debt fossilize. At the beginning seems like a good idea to invest little money in supporting legacy rather than migrating it, but for example, supporting and maintaining COBOL applications is a huge headache. Companies even pay big bucks for formation of new professionals and integrate the old solutions with modern applications is not even that easy since some of the OS are even alien to TCP/IP interfaces let alone modern programming interfaces (and there is nothing worse than an HTML interface on top of the old non ANSI terminal interface, even if you knew where the F21 used to be)
Many systems still run COBOL today
The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
> there are still new 'exciting' things happening in the COBOL space.
Out of interest, does anyone know if new COBOL specs add any major language features or are they just low-profile security fixes and things.
Out of interest, does anyone know if new COBOL specs add any major language features or are they just low-profile security fixes and things.
As someone who works on a 99% Python 2 codebase I think this is a very necessary step. Hopefully one of our larger customers will realise we are still running their critical infrastructure on Python 2 and make enough of a fuss that we can justify the expense.
It was announced in 2014 that support was ending in 2020.
It seems a bit wrong to surprise a customer now.
It seems a bit wrong to surprise a customer now.
We have a more complicated relationship with our customers than that implied. Suffice to say they wouldn't actually be footing the bill.
even if you do the same thing will happen with python 4; these languages are not built with long term stability in mind
The PSF isn't stopping anyone from continuing support. They are only stopping people from calling it Python 2 which is 100% reasonable given that (1) that is trademarked and associated with them and (2) they don't want others' confused about their association with the projects.
By the way this is market opportunity that HN readers might consider. If you think you can make money supporting Python 2, then start working. Who knows it could be a gold mine.
By the way this is market opportunity that HN readers might consider. If you think you can make money supporting Python 2, then start working. Who knows it could be a gold mine.
thats the worst kind of limbo, sort of supported and official but not really.
I fully support them in this. Either you support it right, or you abandon/sunset it clearly.
If someone else wants to step up and do the work, they can always do that on their own.
I fully support them in this. Either you support it right, or you abandon/sunset it clearly.
If someone else wants to step up and do the work, they can always do that on their own.
Indeed, plus people will still come knocking at their door for Python 2 issues. And if you tell them to contact someone else for support people will still be upset.
Imho communicating EOL is the only way to go. Others can pick up legacy support under a different name. People will find them and it will be clear it's a different team.
COBOL has an upgraded version? Besides, legacy is not a perfect excuse for using python 2 since it's so similar to 3 and with some amount of effort you could port it over quite easily.
COBOL has an upgraded version?
Latest version of the COBOL standard is COBOL 2014 (AKA the same year python 3.4 was released).
Latest version of the COBOL standard is COBOL 2014 (AKA the same year python 3.4 was released).
I don't have a stake in this and don't know much about the background, so pardon if this comment is out of touch. Is this the first notice of this date? January 1 is just 16 weeks away, which seems like an awfully short notice for ending security updates of a very popular language.
EDIT: I see now that they mention that 2020 has been the plan since 2014, which seems reasonable.
EDIT: I see now that they mention that 2020 has been the plan since 2014, which seems reasonable.
Nah, we got a 5 year extension about 5 years ago:
https://news.ycombinator.com/item?id=7581434
https://news.ycombinator.com/item?id=7372913
https://news.ycombinator.com/item?id=7581434
https://news.ycombinator.com/item?id=7372913
If you read the article it was explained there, but tl;dr: it was announced in 2014 (that support would end in Jan 1st 2020)
It was announced in 2014 that the sunset day would be further extended to 2020. The original sunset date was 2015, announced in 2008.
That's more than 10 years ago that the intention to sunset python2 at a specific date was announced.
Anybody who, after 2008, started new, serious python2 projects that were supposed to have a life expectancy beyond a few years was rather "optimistic", and anybody who did after 2015 was almost callous, especially if you "played" with other people's money.
That's more than 10 years ago that the intention to sunset python2 at a specific date was announced.
Anybody who, after 2008, started new, serious python2 projects that were supposed to have a life expectancy beyond a few years was rather "optimistic", and anybody who did after 2015 was almost callous, especially if you "played" with other people's money.
I wish Python Software Foundation had worded their announcement differently – in the SW development context, even a plain "support for this version ends on dd.mm.yyyy" sounds more professional and friendly than the word "sunsetting" that has just too many negative connotations nowadays. From past experience it usually means that a startup is pulling the plug or has outright gone bankrupt.
I think you are in a startup echo chamber/bubble. Most of the world doesn't have any negative connotations with that word. You cannot cater to everyone...
Kill it with fire!
Should have been removed years ago.
It actually causes real issues, such as build systems that only support python2 but not python3.
The sooner python2 dies, the better. I need to use both python2 and python3 since otherwise quite several software projects refuse to compile from source. An example is Mozilla's mozjs.
http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h...
Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite. Total clowns working at Mozilla here.
Should have been removed years ago.
It actually causes real issues, such as build systems that only support python2 but not python3.
The sooner python2 dies, the better. I need to use both python2 and python3 since otherwise quite several software projects refuse to compile from source. An example is Mozilla's mozjs.
http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h...
Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite. Total clowns working at Mozilla here.
> Total clowns working at Mozilla here.
Was the cheap shot really necessary?
Was the cheap shot really necessary?
It is a work in progress: https://ahal.ca/blog/2019/python-3-at-mozilla/
> Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite.
Mozilla is not in charge of Rust in any way.
Mozilla is not in charge of Rust in any way.
Dependencies? I helped upgrade a couple third-party modules, too. That's part of the job. If you choose to use a dependency, you're vouching for it. That means if the current version of the language no longer supports your favorite library, you need to fix the library, or find a new one. If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips.
If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
Apple took only 3 years to go from first announcing a new CPU architecture to releasing an x86-only OS. 2 years later, Rosetta stopped working, so there was no way to run old apps on current hardware at all. That's got to be one of the advantages of proprietary systems. It's amazing what you can accomplish when you have no choice. People complained a little but they got it done.