Are You Ready for the End of Python 2? (wired.com) 130
"Users of an old version of the popular Python language face a reckoning at the end of the year," reports Wired, calling it a programmer's "own version of update hell."
The developers who maintain Python, who work for a variety of organizations or simply volunteer their time, say they will stop supporting Python 2 on January 1, 2020 -- more than a decade after the introduction of Python 3 in December 2008. That means no more security fixes or other updates, at least for the official version of Python.
The Python team extended the initial deadline in 2015, after it became apparent that developers needed more time to make the switch.
It's hard to say how many organizations still haven't made the transition. A survey of developers last year by programming toolmaker JetBrains found that 75 percent of respondents use Python 3, up from 53 percent the year before. But data scientist Vicki Boykis points out in an article for StackOverflow that about 40 percent of software packages downloaded from the Python code management system PyPI in September were written in Python 2.7. For many companies, the transition remains incomplete. Even Dropbox, which employed Python creator Guido van Rossum until his retirement last month, still has some Python 2 code to update. Dropbox engineer Max Belanger says shifting the company's core desktop application from Python 2 to Python 3 took three years. "It wasn't a lot of absolute engineering work," Belanger says. "But it took a long time because stability is so important. We wanted to make sure our users didn't feel any effects of the transition."
The transition from Python 2 to 3 is challenging in part because of the number and complexity of other tools that programmers use. Programmers often rely on open source bundles of code known as "libraries" that handle common tasks, such as connecting to databases or verifying passwords. These libraries spare developers from having to rewrite these features from scratch. But if you want to update your code from Python 2 to Python 3, you need to make sure all the libraries you use also have made the switch. "It isn't all happening in isolation," Belanger says. "Everyone has to do it."
Today, the 360 most popular Python packages are all Python 3-compatible, according to the site Python 3 Readiness. But even one obscure library that hasn't updated can cause headaches.
Python's core team is now prioritizing smaller (but more frequent) updates to make it easier to migrate to newer versions, according to the article, noting that Guido Van Rossum "wrote last month that there might not ever be a Python 4. The team could just add features to Python 3 indefinitely that don't break backward compatibility."
The Python team extended the initial deadline in 2015, after it became apparent that developers needed more time to make the switch.
It's hard to say how many organizations still haven't made the transition. A survey of developers last year by programming toolmaker JetBrains found that 75 percent of respondents use Python 3, up from 53 percent the year before. But data scientist Vicki Boykis points out in an article for StackOverflow that about 40 percent of software packages downloaded from the Python code management system PyPI in September were written in Python 2.7. For many companies, the transition remains incomplete. Even Dropbox, which employed Python creator Guido van Rossum until his retirement last month, still has some Python 2 code to update. Dropbox engineer Max Belanger says shifting the company's core desktop application from Python 2 to Python 3 took three years. "It wasn't a lot of absolute engineering work," Belanger says. "But it took a long time because stability is so important. We wanted to make sure our users didn't feel any effects of the transition."
The transition from Python 2 to 3 is challenging in part because of the number and complexity of other tools that programmers use. Programmers often rely on open source bundles of code known as "libraries" that handle common tasks, such as connecting to databases or verifying passwords. These libraries spare developers from having to rewrite these features from scratch. But if you want to update your code from Python 2 to Python 3, you need to make sure all the libraries you use also have made the switch. "It isn't all happening in isolation," Belanger says. "Everyone has to do it."
Today, the 360 most popular Python packages are all Python 3-compatible, according to the site Python 3 Readiness. But even one obscure library that hasn't updated can cause headaches.
Python's core team is now prioritizing smaller (but more frequent) updates to make it easier to migrate to newer versions, according to the article, noting that Guido Van Rossum "wrote last month that there might not ever be a Python 4. The team could just add features to Python 3 indefinitely that don't break backward compatibility."
Believe it when you see it (Score:3)
I think it was for the 16.04 release that Canonical announced that they tried but failed to exorcise Python 2.x from the standard distributions. They said there were so many entries in the application repositories that were dependent on it.
I don't think they managed it for 18.04 either. I just connected to one of my 18.04LTS systems and the default Python is still 2.7.12.
Any news on what they intend for 20.04? My money is on the "they have given it up" square.
Re: (Score:2)
> Any news on what they intend for 20.04? My money is on the "they have given it up" square.
Even 18.04 creates substantial concern (as does e.g. 19.10)-- because it means the distro maintainer has to maintain it when upstream has gone away. I do think python is a fairly lightweight package to maintain, but there's still the possibility of e.g. security issues with no maintainer (without a standard contact point, etc).
IMO the Python guys should give one last very short extension of partial support-- 6-12
Re:Believe it when you see it (Score:5, Insightful)
IMO the Python guys should give one last very short extension of partial support
2020 IS the extension. It was supposed to be sooner. If you give them an extension, they'll just ask for anotherone.
The year 2000 problem had a hard date.
Re: (Score:2)
Yes, but Python itself wasn't ready for the original date. Now the language and the transition tools are good, but we have a few problematic laggards.
Re: (Score:2)
Re: (Score:2)
I can't wait for the end of Python too.
Re: (Score:2)
I can't wait for the end of Python too.
The end of Python two is imminent. It's the point of the article.
Is it really that hard? (Score:5, Informative)
5 years ago I had problems upgrading due to library support (mysql in particular, but there were others).
These days there are none that I encounter. Updating code is mostly a case of checking the print statements and the divide operations (for integer vs floats). It didn't take long to update everything.
I have more problems from both 2.7 and 3.x being present on the same platform and the wrong interpreter being invoked by the OS, which then has to be told more explicitly.
Re: (Score:3)
Even Red Hat only provided core system support for Python 3 in RHEL 7 starting on 2019-08-06. Most companies that already have servers deployed are reluctant to make a system change they're not compelled to for a compelling business reason. I'd anticipate that it will be at least 5 years before the switch is complete for most companies.
It's not so much "fixing your code" it's that when you do "pip install" with the necessary dependencies, there are often a chain of unmanaged and untested dependencies that d
Re: (Score:2)
A decade of warning that support will end seems a compelling business reason to me.
Redhat is certainly at fault with not supporting python 3 in RHEL 7 in a timely fashion and so put companies with critical infrastructure in a difficult position.
If my business was dependent on python and RHEL 7, I would have reconsidered my use of RHEL 7 a long time ago.
Re:Is it really that hard? (Score:5, Insightful)
A decade of warning that support will end seems a compelling business reason to me.
A compelling business reason is "will make/lose money." A decade of warning isn't losing anyone money.
This is especially true for users of Redhat, since Redhat is willing to support Python2.
Re:Is it really that hard? (Score:4, Interesting)
A decade of warning that support will end seems a compelling business reason to me.
A compelling business reason is "will make/lose money." A decade of warning isn't losing anyone money. This is especially true for users of Redhat, since Redhat is willing to support Python2.
But that is not the only compelling business reason.
Knowing that "my servers will be running smoothly, and not losing me any money, in five years time, and without incurring unnecessary and exorbitant costs over the time frame or incurring serious security violations that will get the company name in the press" is a compelling business reason also.
Even though planning for next fiscal year has become "long term planning" in business in recent decades not mean that is a good business practice.
Re: (Score:2)
Knowing that "my servers will be running smoothly, and not losing me any money, in five years time, and without incurring unnecessary and exorbitant costs over the time frame or incurring serious security violations that will get the company name in the press" is a compelling business reason also.
That has nothing to do with Python2/3
Re: (Score:2)
> That has nothing to do with Python2/3
Doesn't it? How many system critical utilities still run on Python 2 and will for the expected life of the servers involved? There are many software components in the world which have been obsoleted over time, and which are still maintained for specific obsolete operating system releases. We're seeing similar issues even today with SMB 1, and with SSH 1. There are older systems with important data that will be very painful to migrate to newer operating systems.
Re: (Score:2)
How many system critical utilities still run on Python 2 and will for the expected life of the servers involved?
Hopefully not many. Python isn't a language suitable for system critical utilities. For that you'd want a language that can catch things like type errors at compile time.
Regardless, Python2 will receive security updates for many years to come, so it's not urgent, and the lack of new development on the language is going to reduce the introduction of new bugs. The main reason I see to change to Python3 is when the library support for Python2 goes away. That's when you need to start worrying about the end of
Re: (Score:2)
A decade of warning that support will end seems a compelling business reason to me.
A compelling business reason is "will make/lose money." A decade of warning isn't losing anyone money.
This is especially true for users of Redhat, since Redhat is willing to support Python2.
But that is not the only compelling business reason.
Knowing that "my servers will be running smoothly, and not losing me any money, in five years time, and without incurring unnecessary and exorbitant costs over the time frame or incurring serious security violations that will get the company name in the press" is a compelling business reason also.
That is literally what is covered by RedHat's support; if security engineering is required, they'll have to do with their own engineers, since upstream won't be supporting it. What you describe is the situation for non-supported distros.
Re: (Score:2)
Well, Redhat is now in the position of supporting a Python 2 fork until the EOL of RHEL 7, so companies still using Python 2 on RHEL aren't really in that bad of a spot. You'll still get security patches from Red Hat, though I wouldn't expect much else.
Re: (Score:2)
> Well, Redhat is now in the position of supporting a Python 2 fork until the EOL of RHEL 7
No, they are in the position of supporting their published software until the end of their contracts. The end-of-life of their published operating systems is approximately 10 years: that durability is one of the features people pay for with commercial software. The end-of-life of Python 2, which is open source software, is in 2020. They've also published a system upgrade peth with RHEL 8, though not all older softw
Re: (Score:2)
Guido is certainly at fault for lacking the competence to develop a language that does not require an incompatible revision, if in fact it really did, another question worth asking.
I can't think of a single language with multiple major revisions that didn't have a version increment that broke existing code. That goes double for a language with multiple major implementations.
But most languages upgrade in such a way that the compiler can see and report the incompatibility. When C++ moved to two phase name lookup, some of my code broke, but the compiler told me about it.
Re: (Score:2)
Erm... no. This happened to me with GCC in about 2010.
It was an easy fix. Throw in a few typenames and it was all good.
Re: (Score:2)
Re:Is it really that hard? (Score:5, Interesting)
My scheme involved file by file, putting in the from __future__ stuff and getting it to run and pass regression the same in both 2.7 and 3.
Once everything is converted, Keep testing on both for a while.
Any code that was too 2.7 or 3.x specific to work in both got changed. That was usually around library support (sockets - I'm looking at you).
All my stuff is kept very modular. I can see how it could be difficult with the big circular dependencies like you get in Web frameworks - I'm sure glad I don't have to use those.
Re: (Score:2)
making your own stuff run isn't really all that hard it's all the dependencies.
doesn't help that the depencies often need to be specific versions or it wont run and dependencies dependencies because there's no social contract of keeping interfaces the same.
Re: (Score:2)
Re:Is it really that hard? (Score:5, Informative)
I just finished upgrading a rather large project. Automatic upgrade tools did a decent job upgrading, but they introduced a lot of trash into the code that I had to later remove. They also messed up imports pretty badly.
The most troublesome part of upgrade for me was split of strings to str and bytes - I had to add a lot of encodes/decodes as suddenly libraries started spewing out incompatible types. Add to this inadequate testing set and it took quite a while to find all places that required it.
Second most troublesome thing were dead libraries - they sometimes died 6+ years ago and no one bothered to upgrade them to py3. For some I found separate py3 forks, but one I had to fully replace.
Baked in O/S release versions are the problem (Score:4, Interesting)
We wanted to install python onto our Solaris servers 6 months ago, the base release from the supplied repo? Yep, v2! It would be a manual task for someone to find and distribute a v3.x to the hosts. So what did we do? That's right, the lead admin simply took the v2 release from the repos as it was easier to install automatically and it would be maintained automatically by the vendor. The only saving grace is that in the end we only ended up with about a dozen scripts running on each host.
If the vendors knew the end of v2 was coming, which they must have done, they need to ensure it's not the default release version in their release repos so people don't rely on them for it. The problem is that a lot of the Python based software in the rest of the repos is coded to use v2, so the once more the lazy vendors will take the easier option.
Re: (Score:2)
It's trivial to write code that is compatible with both. I learned on 3.4 and had to test on 2.7 for the scenario you described.
The only time I was thrown for a loop was when I had to automate something written on Python 2.3, but GreenHills Software is for certified bits and I don't think their lag is going to change anytime soon. The latest version brought 2.5 (around the time 3.6 was released for main stream).
Re: (Score:2)
It's easy. But, not trivial. I do it a lot having written a couple different libraries that way. It's annoying being both prevented from using cool new features and needing to know where all the landmines are so you can avoid writing something that will fail in one version or the other. Yes, let's try to use unicode and if it throws an error we'll use a str instead and perform that code every single time. Or lets try to deal with Py2's weird ass imports with Py3's better version and use the one weird method
RHEL 8 supports python 2 (Score:4, Interesting)
So, in practical terms, python 2 is going to have some level of support for another decade.
Re: (Score:2)
And of course, no support is needed. What, are the Python police going to be checking?
Re: (Score:3)
Re: (Score:2)
So, in practical terms, python 2 is going to have some level of support for another decade.
And even decades after Red Hat gives up on it, I'm sure that some plucky band of volunteers will be supporting it for those people who are stuck in the past for whatever reason. Just like those who have to run 16-bit DOS programs can still use FreeDOS.
Re: Support for another decade (Score:3)
I wish them well, though we recently caved and upgraded, which is still unnecessarily painful due to some gratuitous breakages, e.g. the unittest framework now returning non-zero on unexpected success. (I admit that Python 3 has some worthy changes, but importing from the future got us the most relevant ones.)
I think the era of "Install Updates Automatically" is over; cp. Apple, which is removing functionality (e.g. MacOS management of iOS apps, effective ad-blocking in Safari)
Re: (Score:2)
In practical terms rhel 7 requires python2 and is supported for another decade. The enterprise distro life cycle is far longer than the python2 eol. Even rhel 6, which comes with python 2.6, not 2.7, as the system default and for yum, is around on extended life support until at least 2024. There are federal agencies that still use rhel 4 and pay for its support to keep that alive. So python 2 is clearly not really going away anytime soon; IBM bought the opportunity to support it.
centos needs an 7 to 8 easy update tool! (Score:2)
centos needs an 7 to 8 easy update tool!
well yeah (Score:2)
i've been reaxy for the death of python 1, 2 and 3 for quite some time now.
Re: (Score:3)
Yup, the headline really should have been "Are you ready to give up Python?"
I read all of the people above and their experiences and I just can't relate. With statically typed languages, upgrading a dependency or a language version either works or doesn't work. None of these hidden landmines.
Stop breaking Python would be a huge help (Score:5, Interesting)
The idea that they won't completely break things with Python 4 is a great friggin idea!
I have used programs written for Python 2.7 - they won't work in Python 2.6 or 2.8, you need exactly 2.7. Other programs I use need exactly 2.8.
Backward compatibility really isn't that hard. I have Perl I wrote 20 years ago, it still runs fine. Perl has added a lot of new stuff, they didn't randomly break stuff that has always worked. C from the friggin 1970s mostly still works.
How Python does things:
2.6 somefunction(Foo, fum)
2.8 somefunction (Fi, foo, fum)
3.0 somefunction (Fi, foo)
How sane languages do it:
V1 somefunction (Foo, fum)
V2 somefunction (Foo, fum, [Fi])
You can add an argument without breaking everything, Guido - you just add it to the end as an optional argument, rather than making it the new first argument!
The breakage, rather than paying any attention to backward compatibility, really turned me off to Python. It's kinda sad that they are only thinking about MAYBE not continuing such stupidity, but at least they are thinking about it.
Backward compatibility isn't always an EASY problem, but it's very much a SOLVED problem. Consider, for example, the Linux kernel added IPv6 support throughout the kernel without breaking anything from IPv4. In fact, they did it in such a way that applications written for ipv4, using system calls such as recvfrom(), will often "just work" with IPv6 - the programmer doesn't necessarily have to do anything to support IPv6. Linux made it not only backward compatible, but *transparently* backward compatible when possible. The Python team could probably learn some techniques from the kernel team and others who have done this. Lots of people have handled backward compatibility, how to do it is well known.
In the worst case, what if an established practice just can't work with the new thing, such as sockaddr_in? Do you change sockaddr_in so that all of the existing code breaks? No, the kernel simply added sockaddr_in6. While at the same time continuing to encourage people to use the generic sockaddr, which always worked for IPv4 sockets, Unix sockets, and now IPv6 sockets. You REALLY don't have to keep breaking existing code every time you add a new option.
Re: (Score:2)
Great post!
I just wanted to point out that while I love Perl, it does sometimes have breakages in new versions, too. I recently had to fix a script at $EMPLOYER that had stopped working in RHEL7. It turns out it was using some modules from Perl 4 (like "find.pl") that I had to upgrade to their Perl 5 equivalents because the Perl 4 modules had finally been removed. Fortunately, that was pretty easy, as the new modules had almost exactly the same syntax as the old ones (and the old ones were really just ca
Perl5 came out in 1994. Compatible for 25 years (Score:2)
> I recently had to fix a script at $EMPLOYER that had stopped working in RHEL7. It turns out it was using some modules from Perl 4 (like "find.pl") that I had to upgrade to their Perl 5 equivalents
You were dealing with Perl 4 recently. It's worth noting Perl 5 came out in 1994. So 25 years after the old syntax was deprecated, it was removed. Python can't maintain compatibility for 25 months. From 2006-2009, there were three incompatible versions of Python.
The new releases of Perl 5 are actually Perl 6
Re: (Score:2)
No doubt! I should have mentioned in my post that th
Re: (Score:2)
perl6 is now called raku (as of 10/19).
Yes, python breaking compatibility was just gratuitous.
For example, when perl5 -> perl6, they wanted new functionality for print [that would have been incompatible]. But, instead of breaking print, they created say which is the "new" print--leaving print the same. And, say has been backported to perl5 [as well as a number of other new features]. For each one, the perl5 code must explicitly state that they want the new/updated stuff on a per file basis.
IIRC, perl6/ra
Re: (Score:2)
There was no official 2.8 release. So if you designed around it, that's your problem.
2.6, 1.7, 3.0 (Score:2)
That's right, I misspoke. 2.8 was officially un-released
For official releases, it's 2.6 in 2008, 2.7, then 3.0 - three mutually incompatible languages in three years.
In contrast, another commenter mentioned that Perl recently removed syntax that was deprecated in 1994 - 25 years ago.
Re: Stop breaking Python would be a huge help (Score:2)
Re: (Score:2)
Backward compatibility isn't always an EASY problem, but it's very much a SOLVED problem.
Open for extension, closed for modification.
How hard it is depends on how early you plan for the future.
Re: (Score:2)
I have used programs written for Python 2.7 - they won't work in Python 2.6 or 2.8, you need exactly 2.7. Other programs I use need exactly 2.8.
(a) I'm sorry you had to deal with poorly-written (or poorly-adapted) programs. I'm a professional Python developer, and I have been writing programs since Python 2.6 or so that would work unmodified on Python 2.6, 2.7, or 3.0 or newer. It is possible.
And there's an automated tool that adapts 2.x code to run under 3.x. I've used it; it works well.
And since peopl
Re: (Score:2)
You seem to perhaps be under the impression that I want Python to suck. I'm an open-source programmer and teacher of programmers, not a Microsoft sales rep. I very much do not want the tools we have to use every day to suck. I want them to STOP doing things that suck.
Yes, I had a typo - obviously it went from 2.6 to 2.7, not from 2.6 to 2.8.
2.6, 2.7, 3.0 - three mutually incompatible languages in three years.
They literally broke "hello world", so I don't quite buy the "poorly written programs" argument.
You
Re: (Score:2)
You seem to perhaps be under the impression that I want Python to suck.
I'm under the impression that you used very insulting language to refer to the Python devs and the decisions they made.
Maybe you don't think that was insulting, but I sure do.
I did not speculate as to why you used insulting language. Also, frankly, I don't care. Either you are correct, and there has been a conti
Re: (Score:2)
I'm trying to understand where you are coming from here.
Would you consider yourself a fan of Python?
Have you used other languages, for more than a year or two?
Download and used programs that other people wrote, for more than a year or two?
You asked for an example of a stupid change.
A couple days ago I tried to use a Python program that worked fine with Python 3.7, it doesn't work with Python 3.8 because when they added a parameter to codetype they made the new parameter mandatory. Rather than having it def
Re: (Score:2)
I'm trying to understand where you are coming from here.
Okay. I'm trusting that you aren't trolling me and this is actually some kind of misunderstanding.
You got modded up to +5 level with some criticisms of Python. But the criticisms made no sense to me. You said that functions had their arguments changed egregiously, but your examples were made-up nonsense. Every single time I asked for real examples you changed the subject. Thus, I am frustrated in trying to talk to you about this.
Also, I spent some
Re: (Score:2)
>> A couple days ago I tried to use a Python program that worked fine with Python 3.7, it doesn't work with Python 3.8 because when they added a parameter to codetype they made the new parameter mandatory. Rather than having it default to the 3.0-3.7 behavior when the new argument isn't present.
> It's this: what specifically was the problem? Please give me enough information so that I can look it up for myself.
I'm not sure how I can possibly be more specific. Making a new parameter to codetype() M
A bunch of breaking changes between 3.5 and 3.6 (Score:2)
Btw again as far as "it was a one-time thing" between 2.6 and 2.7 and 3.0, here are a few of the breaking changes between 3.5 and 3.6, for example:
open() no longer allows using system-appropriate newlines via the U flag for text files (+).
sqlite3 no longer commits an open transaction before DDL statements.
On Linux, os.urandom() now blocks
When importlib.abc.Loader.exec_module() is defined, importlib.abc.Loader.create_module() must also be defined.
Servers based on the socketserver module, including those defi
Re: (Score:2)
I'm not sure how I can possibly be more specific. Making a new parameter to codetype()
Please tell me what you mean by codetype()
Do you mean types.CodeType? This is what I find when I Google search for Python codetype [google.com] but that doesn't seem likely.
I'm sorry but I don't know everything about Python, and I haven't heard of this codetype, and Googling it didn't find it for me, and I can't read your mind.
Is codetype even part of Python, or is it something you got using pip install?
2.6, 2.7, and 3.0 are incompati
Re: (Score:2)
I think I've come to understand two points, or two things about where you are coming from, thanks.
> You angered me by using insulting and dismissive language toward the Python core devs
I've done stupider things than removing a core a statement from a language (and replacing it with a method). Just a couple of weeks ago I FORGOT to take a final. That was really stupid. I've also done this exact same type of stupid thing, what I called the "solved problem, problem". Which looking at a hard problem and en
Btw one very simple solution (one cool trick) (Score:2)
Speaking of looking at how other people have solved a hard problem, there is an extremely simple strategy that solves half the problem. It makes it a non-issue for users. Users never have to try to figure out which version they need to make things work.
This one cool trick also makes it easier for devs. You can use whichever dialect of Python you choose, knowing that if it works today it will keep working.
We use it in TLS so that a browser that supports any version of TLS can talk to a server running any ve
Btw that's only easy in retrospect (Score:2)
Btw it occurred to me that may seem condescendingly simple.
It is simple only after somebody points it out. It's obvious *in retrospect*.
As far as I know, nobody pointed it out, the idea never came up. It's not something that necessarily pops to mind unless someone goes looking for compatibility strategies.
Re: (Score:2)
It works (Score:4, Insightful)
print is a great example since almost every script uses it.
Therefore changing it in a non-compatible way broke every script.
There is absolutely no need for that. Pretty much every other language improves their print / printf / echo / say without breaking the old syntax. Look at man echo from 25 years ago compared to man echo in the newest Gnu version. A lot had been added. And echo "hello world" still works just as it did 25 25 years ago.
Re: (Score:2)
When using the interpreter directly or just banging out something quick and dirty, Python3 annoys me to no end because I always have to put ( ) around everything, when all I really want to do is a simple "print foo".
I can understand that by making "print" a method instead of a keyword means you can do a lot more with it. But I really wish they had kept the "print" keyword around in Python3. I would have no problem if any new and improved functionality was only in the print(..) version either.
2.6, 2.7, 3.0 (2.8 release was officially un-relea (Score:2)
You're right, 2.8 was officially un-released
For official releases, it's 2.6 in 2008, 2.7, then 3.0 - three mutually incompatible languages in three years.
Contrast another commenter mentioned that Perl recently removed syntax that was deprecated in 1994 - 25 years ago.
Why can't they (Score:2)
Keep compatibility with previous versions? Put a modifier at the top of your code as to how it gets interpreted. Version 2 or 3, done. Maybe this is why I stay away from code.
Its going to be hard for us (Score:5, Interesting)
Re: (Score:3)
I work at a Fortune 500 that has over 1 million lines of Python code that only exists within our company intranet. We don't license it to anyone else for the most part.
"For the most part" - right there you've basically negated the previous statements entirely. "We don't do it" is not even remotely the same as "we hardly ever do it". Dealing with edge cases is what eats up 80-90 percent of a coders time, at least if my personal experience is any guide.
Re: (Score:2)
Well if you're a Fortune 500 then any blanket statement about their whole code base is likely to be wrong. The point here is that nobody else will help them maintain this code and the difference between nobody and almost nobody is splitting hairs. It's fine to point it out when it makes a difference for the system - even if we're not handling the exception as such do we need to do something to identify/exclude these, give you manual controls, throw errors, send alerts and so on. But if you derail a discussi
Re: (Score:2)
That's just technical debt. Every company has it. If its as large an org as you state then they should be working on ways to eliminate debt. If not, well, thats how the cookie crumbles.
Re: (Score:2)
Re: (Score:2)
There are other options beyond doing the work of moving to Python 3 (though, in general, I think upgrading to Python 3 is worth it over the long haul).
As you know, Python 2 isn't going to cease to exist of course. If you have code that is working, and it really is on a closed system, there are some cases where it may be acceptable to not upgrade it. Another option is to pay a 3rd party to continue to update py2 with security fixes.
Re: (Score:2)
Yeah it won't cease to exist, but from an information security standpoint we can't keep using something that isn't getting security fixes. I totally agree with you Py 3.x is much better than Py 2.x. The problem is we have a lot of Python code that is over 10 years old now that has largely been neglected on maintenance yet still actively used every day. This experience has served as a reminder to me of why IBM is still sells a low volume of mainframes every year.
Corporate IT issued a blanket statement that t
python 2 print (Score:2)
Yes, I switched back to Perl 4 in 2009. (Score:2)
No problems with python whatsoever.
Re: (Score:3)
Perl 6 died earlier this year, and good riddance to it. Perl 5 is still strong and doing fine, thank you.
Python XP (Score:2)
Re: (Score:3)
I'm still using Windows 3.11 and Trumpet Winsock, you insensitive clod.
Re: (Score:2, Interesting)
Says it all really (Score:2)
A saner development cycle would have said 3 is here, 2 will only get security fixes here on out and will be end of lifed, just run the damned 2to3 script, fix the minor differences and get on with it.
Re: (Score:2)
The problem was that early releases of 3 were terrible - substantially slower and broke compatibility unnecessarily in many places. It took years and multiple point releases to fix that.
Re: (Score:2)
Python 3 still breaks compatibility unnecessarily in places, e.g. unittest; hence the abandonment of the strategy of voluntary adoption.
Re: (Score:2)
The solution is simple (Score:2)
you shal not break old grammar! (Score:3)
Re: (Score:3)
To language designers: there is a simple rule: Extend what you want. Pork away. But, under no circumstances break any old language grammar.
I think that's a good rule of thumb, but poor as an absolute, because it forces you to live with mistakes in perpetuity. The original Python got a surprisingly large number of things "right", but after the 1st decade or two, they did identify some things that should be changed, along with a number of things they really just wanted to improve. I am fully aware of the pain of breakage due to e.g. a grammar change, but at the same time, it would really suck to be forced to live with every single design decisio
Re: (Score:2)
I agree 100%, but it seems impossible to get new programmers to follow that. To often I hear that "XYX" is *better* than "ABC" and the interface is changed - and lots of users find themselves with mysteriously broken code.
It seems like the same mindset that causes Microsoft to change their icons every year or two, or making minor useless changes in the user interface. Its change made by people who's world revolves around their code, and who don't understand that to their users, its just one of many tools t
Yes. (Score:2)
Yes, I'm ready for the end of Python.
What's the 2 for?
python (Score:2)
If you want something quick that'll work today. write it in Python, it's a great language.
If you want something that'll work tomorrow, for god's sake, use something else.
My father (Score:4, Funny)
actually (Score:2)
ready for end to all Python, because I have to look at the code
Re:Fuck Python (Score:4, Interesting)
Re: Fuck Python (Score:4, Insightful)
Except that it's flexible and fast enough for real work. It gets used quite effectively in big iron systems, games, network applications, and other demanding tasks.
Easy to learn does not mean too simple to be useful.
Re: (Score:2)
Re: (Score:2)
Now I really want to see VB's machine learning libraries.
Re: (Score:2)
You jest, but there are probably Azure bindings.
Re: (Score:2)
My understanding is that Microsoft at least made it so that dynamic libraries are usually language-portable within the platform.
You can probably use all the C stuff, or whatever C flavor they use over there.
There are things to dislike about VB, but lack of capabilities isn't actually a major shortcoming.
Re: (Score:2)
There are a lot of similarities, and the kind of people who used to make nightmare VB projects are now doing the same thing in Python.
One thing has Python over VB is the vast number of libraries to do just about anything you might want to do. Though on the other hand the one thing VB has over Python is that it makes it simple to throw together a basic UI.
Re: Fuck Python (Score:2)
Precisely. At least VB didnâ(TM)t break compatibility every version.
Re: (Score:2)
Re: (Score:2)
Python is a bit like node.js. Just with fewer packages doing the same shit and at least most of the packages not abandoned years ago.
Re: (Score:2)
Re:On what industry? (Score:5, Insightful)
I would also argue that Python has a shorter development time because fewer bugs are found prior to deployment than in statically-typed languages, and you are encouraged to depend on all of the poorly-maintained libraries that everyone above is complaining about.
It's essentially credit card programming. Get something inmediately and pay the technical debt with interest later.
That's not necessarily a criticism, by the way. Time to market matters. But I much prefer programming to debugging, so Python is not for me.
Re: (Score:2)
Languages like C or C++ are 30+ years old, still being updated nowadays, and v1.0 programs still work today.
Speak for yourself. Some of my C++ code broke when they introduced two phase name lookup.
Of course, it caused a compile error that was trivial to fix so it was reasonably painless. But still, that previously working code does not work today.