Python 2 Sunsets in 107 Days. JPMorgan Isn't Ready (techrepublic.com) 110
In 107 days, Python 2 -- first released in 2000 -- will officially sunset, according to an announcement this week by "volunteers who make and take care of the Python programming language."
But according to TechRepublic, not everybody is ready: Given Python's popularity and ubiquity, the amount of business logic hinging on Python is quite vast, presenting an issue for organizations still clinging to Python 2. JPMorgan's Athena trading platform is one of those applications -- while access has only been available directly to clients since 2018, the Athena platform is used internally at JPMorgan for pricing, trading, risk management, and analytics, with tools for data science and machine learning. This extensive feature set utilizes over 150,000 Python modules, over 500 open source packages, and 35 million lines of Python code contributed by over 1,500 developers, according to data presented by Misha Tselman, executive director at J.P. Morgan Chase in a talk at PyData 2017.
Migrating 35 million lines of code from Python 2 to Python 3 is quite the undertaking -- and JPMorgan is going to miss the deadline, according to eFinancialCareers, stating that JPMorgan's roadmap puts "most strategic components" compatible with Python 3 by the end of Q1 2020 -- that is, three months after the end of security patches -- with "all legacy Python 2.7 components" planned for compatibility with Python 3 by Q4 2020.
Modern developer practices are needed to maintain a project of this scale -- fortunately, JPMorgan uses Continuous Delivery, with 10,000 to 15,000 production changes per week, according to Tselman.
The eFinancialCareers site argues that banks "have been dragging their feet," adding that JPMorgan is not the only bank that still hasn't migrated to Python 3.
The Python volunteers are pointing concerned individuals to the Python 2.7 Countdown Clock, and their announcement also links to a list of support and migration vendors, adding "If you can pay to hire someone to help you, post on the job board or hire a consultant. If you need free help from volunteers, look at this help page."
But according to TechRepublic, not everybody is ready: Given Python's popularity and ubiquity, the amount of business logic hinging on Python is quite vast, presenting an issue for organizations still clinging to Python 2. JPMorgan's Athena trading platform is one of those applications -- while access has only been available directly to clients since 2018, the Athena platform is used internally at JPMorgan for pricing, trading, risk management, and analytics, with tools for data science and machine learning. This extensive feature set utilizes over 150,000 Python modules, over 500 open source packages, and 35 million lines of Python code contributed by over 1,500 developers, according to data presented by Misha Tselman, executive director at J.P. Morgan Chase in a talk at PyData 2017.
Migrating 35 million lines of code from Python 2 to Python 3 is quite the undertaking -- and JPMorgan is going to miss the deadline, according to eFinancialCareers, stating that JPMorgan's roadmap puts "most strategic components" compatible with Python 3 by the end of Q1 2020 -- that is, three months after the end of security patches -- with "all legacy Python 2.7 components" planned for compatibility with Python 3 by Q4 2020.
Modern developer practices are needed to maintain a project of this scale -- fortunately, JPMorgan uses Continuous Delivery, with 10,000 to 15,000 production changes per week, according to Tselman.
The eFinancialCareers site argues that banks "have been dragging their feet," adding that JPMorgan is not the only bank that still hasn't migrated to Python 3.
The Python volunteers are pointing concerned individuals to the Python 2.7 Countdown Clock, and their announcement also links to a list of support and migration vendors, adding "If you can pay to hire someone to help you, post on the job board or hire a consultant. If you need free help from volunteers, look at this help page."
Comment removed (Score:3)
Re:Neither is Apple? (Score:4, Informative)
"The older Python language, version 2.7, is being deprecated in macOS 10.15 Catalina and won't be included in macOS 10.16."
https://www.macobserver.com/an... [macobserver.com]
Catalina will be released October 2019.
Re: (Score:1)
I wish they'd stop releasing half baked crap every year.
Re:Neither is Apple? (Score:4, Informative)
I have no idea if any part of MacOS uses python but it ships with Python2
Catalina ships with Python3 as /usr/bin/python3 and Python2.7 as /usr/bin/python. Start the latter, and you get a warning:
Re: (Score:2)
Correct me if I'm wrong, but I've heard that the recommended way is to not use /usr/bin/python any longer and use /usr/bin/env python to get the correct python environment. That has been the way I have seen it done and is the way that I script it.
Re: (Score:2)
Correct me if I'm wrong, but I've heard that the recommended way is to not use /usr/bin/python any longer and use /usr/bin/env python to get the correct python environment. That has been the way I have seen it done and is the way that I script it.
That used to be the recommended practice - to allow for preferring versions in a user's home directory, /usr/local etc over the system provided version. These days (or rather, since the python 2 migration a long time back...), I'd go one step further and specify the python version as well: "/usr/bin/env python3" or "/usr/bin/env python2".
Think COBOL (Score:1)
Considering they have "no problem" with lack of community support of COBOL, I don't think Python2 retirement is an issue for banking sector. Also what does the article actually mean by "the end of security patches" for a programming language?
Re: (Score:3)
No more fixes to Python 2.x likes these:
- Issue #11144: Ensure that int(a_float) returns an int whenever possible.
Previously, there were some corner cases where a long was returned even
though the result was within the range of an int.
- Issue #11450: Don't truncate hg version info in Py_GetBuildInfo() when
there are many tags (e.g. when using mq). Patch by Nadeem Vawda.
- Issue #10451: memoryview objects could allow to mutate a readable buffer.
Initia
Re: Think COBOL (Score:4, Insightful)
Wrong, commercial distros and LTS ones will have fixes. Stop the FUD
Re: (Score:2)
I wonder how that's going to look a couple of years from now. Is there going to be a committee keeping SuSE, RedHat, Oracle, and such all patching their python2 packages in the same manner? Are we going to end up with a python2 that forks into a slightly different beast with every commercial vendor picking what gets fixed and doesn't?
I know C++ turned into a mess with vendors picking different standards. I wouldn't know much personally... I only ever touched MSVC++ in the professional world and very minim
Re: (Score:2)
Red Hat is the leader of commercial Linux by far, 90% the fortune 500 use them (including JP Morgan, the subject of this article). the future for big businesses will mostly be what Red Hat does with PHP 2.7. Oracle Linux is compiled from Red hat source (as is CentOS).
There is ISO standard C++, and then there are vendor extensions (for example GNU extensions). The ISO standard stuff isn't a mess. The vendor extensions are a funny land, for example Intel's compiler supports many GNU C and C++ extensions
Re: (Score:2)
ha, meant to write Python 2.7
PHP is example of Red Hat doing back porting.
Re: (Score:2)
The issue is whether they are paying customers.
Red Hat is definitely the biggest with regards to commercial Linux being paid for, but unless IBM is REALLY REALLY careful, that will actually change over time. There are companies with strict anti-IBM policies since IBM is a known predator with regards to large firms.
I would imagine that there will be a fork and maybe even a rename (almost like MySQL) and eventually we'll see someth
Re: (Score:2)
I guess the patches are for libraries built on that platform will no longer be maintained at all, nothing to do with the language so much as nobody caring about them any more.
Buy I imagine JPMorgan has enough money to buy developers to bring the whole system in-house and treat python 2 as if it was a internal product.
Unless they're cheapskates taking as much as they can for free....
Re: (Score:2)
I didn't know JPMorgan's primary business was programming language development. There is a reason business often outsource things even though they could do it in-house - it doesn't fall within their primary mission to run e-mail or run a website and to do so would be a distraction.
Re: (Score:2)
> I didn't know JPMorgan's primary business was programming language development.
Welcome to the future grandpa. JPMorgan's primary business is staying competitive by any means necessary...
(which probably includes insider trading... but that's another topic).
McDonalds is now pioneering a kiosk ordering system.
Disney is creating a streaming service.
Oracle is creating a cloud platform. Remember that online bookstore... yes, Oracle is competing with them DIRECTLY.
Re: (Score:2)
> McDonalds is now pioneering a kiosk ordering system.
Pioneering? I first used a kiosk at McDonald's in 2015.
Re: (Score:3)
Also what does the article actually mean by "the end of security patches" for a programming language?
Python still includes things like libraries, runtime, etc. Things that the likes of Red Hat will still happily be providing security updates for for the coming decade.
Re: (Score:3)
Not "happily". If the upstream vendor turns off updates, Red Hat will be maintaining their own patched fork and lose much of the point of an open source or free software project. This is aggravated right now by the fact that RHEL 7.7 does include vendor supported python 3.6, but CentOS 7.7 has not been released yet, and the new packages are available only in the "cr" repositories. RHEL 8 has not yet been republished as CentOS 8, so shops that test on CentOS before commercially using RHEL are also being held
Re: Think COBOL (Score:2)
COBOL is supported and has active communities in both open and closed source realms, don't talk in ignorance.
Python 2 will be supported for years in commercial distros
Same crap, different product (Score:1)
Python 2 was due to sunset in 2015, but due to the clamour from corporates it was extended by an extra four years. Cue lots of hand-wringing articles about the now imminent deadline and how the poor banks who had years to sort their systems out didn't, but that it isn't their fault.
The same thing happened with Windows (pick a version): "Yeah, it will be obsolete in X years" "Wait, no, that's not long enough!" 'OK, have another couple of years" extended deadline passes "Right, it's dead now" "You can't do th
Re: (Score:3)
Microsoft at least tries to make Windows backwards-compatible at the application level. Python seems to have decided that they screwed up the second time around, but you can really trust Python 3 to have gotten it right. Or at least right enough for the next couple of years.
Re: Same crap, different product (Score:2)
Python 2 will be supported for years in commercial distros and LTS distros. There is no problem, not for J P Morgan nor anyone else with a brain. This article is lies from Python 3 fans, serious users can ignore
Re: (Score:1)
You make it sound like 4 years is a lot, but it's not. 4 year is virtually nothing. And using MS as reference isn't that helpful either, if it was up to me windows 2000 was still supported - by law, if needed. They sold it, they should support it. Python is open-source so making such demand is illogical, as the answer is 'go support it yourself, here's the source'.
On-topic, it shouts 'stay away from this' though. The guys from PHP did the same, every major version was a PITA for many, breaking a lot of stuf
Re: (Score:1)
Bingo! /. See: Fred Brooks - Mythical Man Month
Programming isn't picking sweet corn. Refactoring from Python 2 to 3 even less so. Anyone who thinks it is is a clueless noob that should be ousted from
Anyone who thinks that a large system, such as JPMC's, can get it reworked in eight years (Python 2's original EOL announcement was in 2011) is, again, a clueless noob. It took longer than eight years to initially build it.
Anyone who *designs* a language according to Agile principles (Minimal Viable Product)
Re: (Score:2)
I assume neither of you have worked with NPM.
Man, that's a mess. A huge mess. A trainwreck. "npm update" is GUARANTEED to break your project and the only way to find out why is to google the errors, because release notes are for noobs.
Think python 2 to python 3 but for the 3000 packages in your project.
Because yeah, require one package (say, "mssql", and it brings 1500 more dependencies)
Re: (Score:2)
The big Windows example was Vista's changes to UAC. When XP launched you could use the features to not run as admin, and it was warned that the next version would make them mandatory. Some companies did that in the early 2000's. Other, often major, companies didn't. That's why some software worked perfectly fine on Vista, and yet so many softwares had UAC hell. The biggest "update" of 7 was finally arriving when most vendors had implemented the changes.
Re: (Score:2)
Python 3 was released in 2008, Python 2 in 2000, so Python 2 has been known to be on the way out for longer than it was around when Python 3 dropped.
Re: (Score:1)
And the same thing has happened in other contexts, with much longer grace periods.
When Solaris 2 shipped, it came with a deprecated Solaris 1 compatibility package. 20 years later (Solaris 11), the new servers no longer had it available. Cue all the developers writing new scripts yelling to be given access to something that was no longer there.
Predictable (Score:4, Insightful)
Poor Guys (Score:5, Funny)
As a non-profit barely hanging on to life [jpmorgan.com], it's no wonder that even with a 4 year extension to the Python 2 sunset they weren't able to afford to make the transition in time. They should probably set up a Go Fund Me or something to finance enough developers to migrate.
Re: (Score:3)
It seems like a silly story. I would expect a big company - or even a small one, if it has even a marginally competent IT staff - to be using a distro which offers specific support terms and a defined lifetime for its products.
RHEL / CentOS 7 include python 2, for instance. That will be supported through August 2021. Need even more time? Well, RHEL 8 still includes python 2.
So, practically speaking, you can keep using python 2 for the next decade, if you wish.
Can't just end support on software like that (Score:2, Insightful)
You cannot just end support on something like Python 2, you can say it's at the end of life, but there will be plenty of large companies happy to provide updated packages, security fixes, etc. If the Python dev's didn't stubbornly break backward compatibility between 2 and 3 for no particular technical reason they wouldn't have so many problems in the transition in the first place.
Re: (Score:2)
yes, and one of those large corporations is Red Hat
Python 2 support will continue for years
Re: (Score:1)
Python 2 should be supported indefinitely... the language and API are stable. Just fix the dozen bugs that are reported each year.
So clearly you're volunteering? Or paying someone to do this?
Re: (Score:2)
So? (Score:2)
Will it cease to function after 107 days?
Re: (Score:2)
This right here, it's a non-story. As long as they are willing to continue using a language version that will never be updated, then they can continue using py2 forever.
Re: (Score:3)
Re: (Score:2)
The core language and libraries will not. However... pip and pypi may well start to break quite badly. We already experienced this with 2.5 and 2.6, and now it's 2.7's turn. Unless you pin every package version including every transitive dependency, expect pip and the like to start to break horribly in the following months.
It's not going to suddenly stop working (Score:2)
Python is open source (Score:2)
Re: (Score:2)
All the Gnome 2 programs had to be renamed in Mate, because Gnome 3 brought their names with it.
If "python3" gets to be renamed to "python", we would have a problem.
Waaa (Score:4, Insightful)
Bunch of cry babies.
You are swimming in cash. Hire someone to do it. You had PLENTY of warning.
Here's a better and a lot cheaper solution (Score:2)
Hire a single developer who will keep their Python 2 interpreter safe and secure and fix whatever expolitable vulnerabilities are found (and usually there's a lot less actual exploitable vulnerabilities than theoretic vulnerabilities which never get exploited).
At the same time they may start slowly fixing/rewriting their code to be compatible with Python 3.
Also it would be great to have someone in the python dev team, so that the fixed code has more chances to be compatible with Python 4.
You pay your money and take your chances (Score:3)
This is the downside to free software -- no corporation to yank your checks from because they're being assholes.
Re: (Score:2)
If your check-yanking theory were correct, companies like Oracle would have gone out of business decades ago.
Re: (Score:2)
You can still write checks, and subsequently yank them, with free software. I'm sure even now JPMorgan could give the python foundation some earmarked funds to have python 2 support continue as long as they need. Or even do it as an in-house project.
But yes, if you base your software dependencies on groups to which you never contribute financially or otherwise, you are at risk of not being their top priority when they are forced to make decisions on how to allocate their limited funds and development tim
Re: (Score:1)
With opensource software, you can pay someone other than the original authors to maintain software you don't want to give up on. The same is frequently not true of closed source software.
JPMorgan Isn't Ready (Score:1)
Will this make them cause another recession? Or engage in more mortgage fraud with Wells Fargo and Bank of America?
JPMorgan should have lost its charter and its officers locked up a very long time ago. Too bad we choose to elect crooked politicians that prop them up with bailouts instead.
Not true, Python 2 supported for years (Score:4, Insightful)
Python 2 will be supported for years in long term support distros. JP Morgan and any other business therefore has no problem.
This FUD from the Python 3 fanbois needs to stop. Businesses aren't interested in the incompatible Python 3 and open source language makers need to learn the lesson of respecting backwards compatibility.
Do they? (Score:1)
Re: (Score:2)
You're talking of the fashion/fad driven consumer realm
serious business server realm is a different matter.
There's this little company called IBM (Score:1)
Re: (Score:2)
no it won't. distros don't make upstream patches unless a developer of said distro works upstream.
if a fix is developed by someone, distros will package them. they will NOT fix upstream issues themselves
Re: (Score:2)
Red Hat, for example, backports patches to older versions of languages
You blather about unrelated things.
Re: (Score:2)
patches from upstream, yes and they will continue to do so as long as they exist. they don't have the manpower to fix upstream stuff the same way microsoft doesn't fix stuff in a third party software
Re: (Score:2)
"Upstream" is irrelevant in this case
Backporting fixes from later versions that are applicable to old is what will be done, and that's all that is needed.
So, no emergency for many many years regarding python 2
Re: (Score:2)
You're counting on a large organization to do the backporting and correctly. They will miss some patches.
Smaller projects don't have the manpower to maintain python 2 and yet we'll still have to ship it because most build systems now seem to use it. We can't build other open source software without it.
Python developers have not learned their lesson either. Python 4 will be incompatible with 3 partially as well. They're going to do it to us again.
How many years have they known about this? (Score:2)
If memory serves it was five years. And yet they did nothing despite the warnings all that time that this day was coming. Excuse me while I find the world's tiniest violin to play while they whine.
JPMorgan has enough money to pay contractors to come in and convert all that code. Perhaps the company will help pay for them by firing the management team that ignored the problem for so long.
And to the business leaders who might be tempted to cry that this is a problem resulting from using open source software
Re: (Score:3)
Python 2 will be supported for years in Ubuntu LTS and Red Hat, SLES, etc.
The business leaders know what the hobbyists and Python 3 fanbois here do not.
Re: (Score:2)
Commercial OS vendors were also slow. RHEL 8 only came out in May, CentOS 8 still hasn't happened, and at this rate it looks like it won't be published before Christmas.
they've been told - they're not listening (Score:5, Interesting)
right from when python3 was created, it was absolutely hopelessly unrealistic of the Python Software Foundation - run primarily by *developers* - to expect that python2 would just "magically go away" when it was c-module-incompatible with python3.
the fact that they put the *same extension* - .py iinstead of .py3 - underlies the naive arrogance and completely unrealistic expectations and total disconnect with industry.
i worked for NC3A (NATO Research) back in 2006. they had a Zope Server which ran on *python 2.1*. python 2.1... in 2006, and it wasn't upgraded in the entire 18 months i worked there! the reason was as follows:
* python 2.1 was released in april 2001
* a year-long evaluation process was initiated with a sponsor, to get them to consider using python 2.1 and Zope
* the decision was made, and that "locked" python 2.1 into what was to be used.
* the sponsor then had to go and find (make the case for) a EUR 10,000 "Security Audit" of python 2.1. this took about 6 months (now we are up to around end-2002 already...)
* the actual "review" took place, which took another year (now we are up to 2003)
* now FINALLY actual software development could take place (on python 2.1... in 2003)
* this took 18 months (now we are up to 2005)
* i get called in on the "Maintenance" cycle, a year later.
now, the reason why this would NEVER be upgraded should be clear: the time taken, as well as the sheer cost of the "Security Audits" is something that is simply out of the question.
additionally, one of the people there used to work on Wall Street. he was responsible for Terabyte-level Databases with over 650 tables. just doing an audit of the use of Credit Card data in those 650 tables took EIGHTEEN MONTHS to plan and schedule all developers to move all applications to ONE table in which Credit Card data would be securely stored.
not actual *implementation*, just PLANNING of the changes to a live database used by thousands of simultaneous developers across the entire company.
the Python Software Foundation is therefore acting in an UNBELIEVABLY irresponsible fashion by failing to continue to support python 2.7, failing categorically in its responsibilities towards users across the world who *cannot contact them* because their developers are under NDA or work in High-Security Environments.
the only reason i can talk about the above is because it was "UNCLASSIFIED" i.e. whilst the *data* was definitely "classified", there was nothing "special" about the code that "any office environment" would not have in a similar situation.
please, somebody, kick the doors in on the Python Software Foundation. they need a wake-up call.
Re: (Score:2)
I know little of the Python Foundation and the language. But from what I have read, the move will cost companies lots of 'real' dollars to move to v3, this could end up giving "Open Source" a black eye. Yes, companies are at fault because they had plenty of time, but this shows how things work in large companies. If stable never change it. A perfect example of this is COBOL and mainframes. When such a big change to a popular language happens, seem all that happens is no one wins.
A large ERP company is
Re: (Score:2)
They don't have to move to V3 since V2 will be supported for years in commercial linux distros. JP Morgan has no problem, nothing to worry about. The author of that article is ignorant and talking out of his ass about JP Morgan's system since the language Python 2 will have years of support by Red Hat and others.
COBOL is changing all the time, a living language with new features added to each spec. What COBOL does that Python did not, however, is respect backwards compatibility. This separates mature l
Re: (Score:3)
I know little of the Python Foundation and the language. But from what I have read, the move will cost companies lots of 'real' dollars to move to v3, this could end up giving "Open Source" a black eye.
I spent 10 years writing 200,000 lines of Python 2. Then I spent 2 weeks migrating to Python 3. So all in all, it took me 10 years and 2 weeks to write 200,000 lines of Python 3.
Writing the equivalent functionality in C# would have taking 30 years.
Companies that are worried about their 'real' dollars should probably be more concerned about other things than the Python 2/3 schism. Like whether they could have been using a more productive programming language.
Re: (Score:2)
Without wanting to put words in the GP's mouth, I suspect in their environment (and other highly secure or critical safety-type environments), the two weeks updating a codebase for Python 3 would have triggered another series of audits.
That is, while it might not have a lot of actual sheer technical overhead, there might be significant overhead caused by the upgrade - as it might be considered a new 'environment', it might mean a new requirement for from-scratch auditing, which is where a lot of the cost
Re:they've been told - they're not listening (Score:5, Informative)
now, the reason why this would NEVER be upgraded should be clear
So what exactly do you expect the PSF should do? You say yourself that this Python 2.1 install should never be upgraded. If it can't be upgraded, ever, then it really doesn't matter what the Python core developers do one way or the other. Because nothing they put out will ever be used by this bureaucratic nightmare of an organisation that you used to work for.
But somehow it's Python's fault that your company was like that?
additionally, one of the people there used to work on Wall Street. he was responsible for Terabyte-level Databases with over 650 tables. just doing an audit of the use of Credit Card data in those 650 tables took EIGHTEEN MONTHS to plan and schedule all developers to move all applications to ONE table in which Credit Card data would be securely stored.
650 tables? Sounds like quite a mess. No wonder it took 18 months to plan. But the relevance to Python release planning escapes me.
Re: (Score:2)
Re: (Score:1)
Where are those mod-up points when I need them...
I think I spotted the problem. (Score:5, Insightful)
This extensive feature set utilizes over 150,000 Python modules, over 500 open source packages
One application is using twice the number of modules than Debian has packages? I feel like that exactly the problem they are actually having. Most likely they already have a terrible feature bugs and security bugs in their software and have no idea about them either.
500 open source packages in one application? It seems they have bigger software engineering problems than just using a retiring language.
Sounds like they are using the programming approach of "just include one more package, who cares where it comes from?"
Re: (Score:2)
Presumably they wrote many of those modules themselves. I suspect their actual problem is lack of coordination. Joe writes some bit of code that does X and it gets turned into a module. Sam writes some other bit of code that does Y, which duplicates a lot of the function of X, and it gets turned into a module.
It sounds like Athena isn't really a "platform" so much as a repository of coding projects.
Re: (Score:2)
Seems like that could be either an internal communications problem or different departmental programming teams have a Not Invented Here problem. Maybe both.
Re: (Score:2)
10,000 updates per week? (Score:2)
It's worse than that - there was a quoted 10,000 updates a week, which is around 1 per minute (assuming working 24/7).
Now if that meant, 10,000 commits a week, then i can see that, it's just written to sound like the application is being updated every minute :(
Whole lotta FUD (Score:4, Informative)
The Python devs have done some really great things, but stories like this just show that somebody will always complain no matter what lengths you go to. Consider:
1) Python is free. /automatically/ convert many of the incompatibilities for you.
2) Python is open source.
3) In 107 days JP Morgan will continue to benefit from the free software they use, but they'll have to start paying people to continue to update it for them.
4) The Python 2 line is now 20 years old. I'm betting that most of the people who whine about backwards compatibility have never maintained backwards compatibility on any software of meaningful size for anywhere near that long.
5) Python 3 is largely backwards compatible with Python 2. Sometimes people make it sound like the syntax is wildly different, when it's not. Also, all of the breaking changes are clearly documented. Further, the devs even supplied a tool (https://docs.python.org/2/library/2to3.html) that can
Python is approaching the age of 30. It's not a perfect language, but it's held up really well. The fact that along the way the devs have come up with new ideas and felt the need for some course correction isn't a surprise to anyone, is it? They announced years in advance that there would be breaking changes coming, they took full advantage of the breaking event to remove a lot of cruft and fix a lot of problems (unifying string types was huge), they provided tools to automate good chunks of the conversion, they continued to support the old way for years, and then extended that for even more years, all for free. And yet still some people are freaking out and criticizing them. This is why we can't have nice things, I guess.
Re: (Score:2)
The first 4 points were great and then you had point 5. Python is getting pushed for enterprise software now. When it was a toy language that was used to make guis faster in Gnome, that was fine. Now that it's used for big enterprise apps, data science, AI and the like, it matters a lot if you break compatibility. Java isn't perfect and has failed us some, but it's backward compatibility is a big deal in these environments.
From a business perspective, you have to do an overhaul on a lot of code. Not al
Re: (Score:2)
Oh, I'm super aware of its use in enterprise software - I've been using Python in large systems for a very long time.
In any scenario, but perhaps especially in an enterprise / business-critical setting, you generally do one of two things:
1) Keep a language/library/etc. at a specific version for a very long time.
2) Test the heck out of it when you move to a new version.
In no case would you do #2 and just rely on somebody else's word that the new version is backwards compatible (well, you could, but it'd be i
This is why COBOL is still in wide use . . . (Score:3)
I find it incomprehensible that a business would place millions or even billions of dollars in activity onto a system where it can't reasonably expect a basic building block to be available and reliable for several decades to come.
Yes, they could take over supporting the language themselves . . . but that kind of takes the point out of using one that already exists.
*THIS* type of event is the reason that "the cranky old dinosaurs" don't switch over to the flashy new languages . . .
hawk, dinosaur
Re: (Score:2)
I find it incomprehensible that a business would place millions or even billions of dollars in activity onto a system where it can't reasonably expect a basic building block to be available and reliable for several decades to come.
So you don't use closed-source COBOL compilers or libraries, I presume? Because if you do, any second now your supplier could go out of business or discontinue the product, and you could lose the ability to buy new licenses even for the current version.
That's not a theoretical problem -- products die from vendor-gone-AWOL, it happens. It is perhaps the one thing that I like the most about open source: that I can trust it to still be there tomorrow.
Re: (Score:3)
That's funny, the big suppliers of closed source COBOL are IBM and MicroFocus. MF is 43 years old, and I'll leave how old IBM is as exercise for student. They aren't going anywhere.
At least the python 2.7 will be supported by backports of fixes in the commercial distros for a few years more. Too bad Python 3.x is another language. Too bad we can't count on open source developers to respect backwards compatibility, the "ooo new shiny , old is boring" mindset poisons it.
Re: (Score:2)
I'll leave how old IBM is as exercise for student. They aren't going anywhere.
Unless you can tell me that they still supply spare parts for Hollerith machines, I don't care how old they are. IBM products get discontinued just like everyone else's. For a more recent software example, IBM Xeena.
Re: (Score:2)
When Iowa State built the ABC replica in the 90s, they pulled the old purchase orders from the university archives, and were able to buy a surprising number of parts from the same suppliers with the same part numbers . . .
hawk
Re: (Score:2)
Err.. the flashy new 29 year old language? Python isn't the new kid on the block and it has evolved over time, just like the older languages. Even C has changed, quite dramatically, since it's inception. Hell, original ANSI C only let you use the first six chars as variable and function identifiers. You'd be nuts if you tried writing C that way today. It's not C's fault if you never upd
Re: (Score:2)
Err.. the flashy new 29 year old language? Python isn't the new kid on the block and it has evolved over time, just like the older languages. Even C has changed, quite dramatically, since it's inception. Hell, original ANSI C only let you use the first six chars as variable and function identifiers. You'd be nuts if you tried writing C that way today. It's not C's fault if you never updated.
Why python2 is seen different I don't get.
But original ANSI C will still compile on a modern compiler and run. See the difference?
Re: (Score:2)
Nope, you misunderstand.
30 year old C, C++, COBOL, Fortran code will still run compiled with modern compiler.
It's that lack of respect for backwards compatibility that is the problem.
Re: (Score:2)
PyPy to the Rescue! (Score:3)
I do not understand ... (Score:2)
What is the problem? Why does anyone think that things need "support", are they so shoddy in construction that they are balls of shit that need the manufacturer to continually play about with them? And so what if the PSF will no longer be playing around with python2 after Dec 31/2019. As it worked on Dec 31/2019 so it will work the following day. And each day following that, for all of eternity! Where is the problem, as I completely fail to see one.
I use Acronis 11 because Acronis 12 sucks massive donk
Re: (Score:2)
Eventually python2 will fall so far down the hole it won't even build. That may be some time from now but it will happen. Things that aren't maintained just stop working.
Re: (Score:2)
For instance the project I am working on, under python2.3 we had a local archive of installable versions of all the needed libs. When we moved to 2.7, we could only get installable
This is a con story, according to the article (Score:2)
"Does this matter? What happens when the PSF stops supporting its old language? Clearly, platforms like Athena will keep working. JPMorgan said last year that it has 2,000 developers working on Athena, and some of them are likely to be diverted to creating security patches. Equally, specialist vendors are offering to support Python 2 beyond the January deadline and banks can always pay for their services."
I'm available (Score:2)
My hourly rate is $480 an hour and I have some availability the first of the year if JP wants to hire me.
oh no! (Score:2)
I feel so sorry for these banks, not.
As if they have no money to:
- fork python2 to bankthon or something and maintain it themselves
- pay somebody to migrate to python 3
Gentoo Linux (Score:2)
Re: (Score:2)
Re: Foolish BANKER JEWS (Score:2)
Re: (Score:2)
Just wait. An AI solution will be right along to take care of the problem.
Re: Foolish BANKER JEWS (Score:2)
An AI solution will be right along to take care of the problem.
Unfortunately, AI will solve everyones problem, including JPMorgan; so that's a plus.