Slashdot Mirror
Why Do Projects Continue To Support Old Python Releases?
On Planet Python, Gregory Szorc asks why many projects continue to support Python releases prior to 2.7, when they are all EOLed (2.4 in 2008, 2.5 in 2011, and 2.6 last October), and Python 2.7 provides a clear upgrade path to Python 3. Quoting: "I think maintainers of Python projects should seriously consider dropping support for Python 2.6 and below. Are there really that many people on systems that don't have Python 2.7 easily available? Why are we Python developers inflicting so much pain on ourselves to support antiquated Python releases? As a data point, I successfully transitioned Firefox's build system from requiring Python 2.5+ to 2.7.3+ and it was relatively pain free."
Shortly after posting, other developers responded with their reasons for using older Python releases. First, Rob Galanakis of CCP (EVE Online) explains the difficulties involved in upgrading a mature commercial project embedding Python. Nathan Froyd adds "I think this list of reasons to upgrade misses the larger point in providing software for other people: You do not get to tell your users what to do. ... Maybe those users don’t have sufficient control over their working environments to install a new version of Python. ... Maybe those users rely on certain APIs only available in older versions of Python and don’t wish to take an indeterminate amount of time to rewrite (retest, recertify, etc. etc.) their software. ... Maybe those users are just rationally lazy and don’t want to deal with downloading, configuring, and installing a new version of Python, plus dealing with inevitable fallout, when the old version has worked Just Fine for everything else."
Some versions of Python don't work on some OSes, mostly those with not-so-sane threading systems. Not that any of this matters, as the OS I can think of off the top of my head with such issues are Win9x OSes or other niche OSes that don't get as many updates as one would like.
There are lots of people that have installed python (or had it installed), but not as many that are willing to upgrade their python installation to the latest version. The jump to python 3.0 is a little tricky because some code is not compatible (which is why we still have 2.x) so there's lots of software that would break if people upgrade.
When developing, it's important to aim for the lowest support level. If all my customers are running offline RHEL 4, I'm stuck with python 2.3.
Let's say I have something in python that was developed on python 2.5 and is in maintenance now. The correct question is why would I demand python 2.7 suddenly? Wouldn't that be kinda bone headed of me?
Why should I do extra work with the express purpose of making my software more demanding in it's requirements?
Get Redhat to upgrade their version of Python, then the developers will use it. Until then if you want to write portable code, you ignore the newer features.
CentOS
Change means bugs. Why would you want to disrupt your production system to fix bugs introduced in a new release? What benefit would there be to you?
The system is built, and it works. Don't touch it unless you have to, or unless it was designed to be upgradeable.
Many Linux distros in wide use still come with Python 2.6 as the stock Python. If you have some little program that needs to be portable, you write for Python 2.6 and test on 2.6 and 2.7.
People aren't converting to Python 3 for the same reason Perl users aren't converting to Perl 6 - it's different and incompatible. Many third party Python 2.x packages were never ported to Python 3. Some were replaced by new packages with different APIs, which means rewriting code and finding out what's broken in the new packages. Newly written programs tend to be written for Python 3, but much old stuff will never be ported.
The Python version included with RHEL 6 (that's the very latest version): 2.6
The Python version included with RHEL 5 (still widely used): 2.4
Thank them for forcing us to keep supporting old versions.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
If all my customers are running offline RHEL 4, I'm stuck with python 2.3.
How do you deliver an application to your offline users? And why can't you deliver an up-to-date side-by-side version of Python along with it?
Maybe users don't want to upgrade, like Mr. Froyd says. But maybe they would upgrade if you gave them a reason to. I'm definitely not a large scale user, but I've never encountered a situation where an older version is more attractive in any way.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
ROTFLMAO.
Python thinks just because they declare EOL on 2.6 that millions of users around the world are going to jump to 2.7?
Can they guarantee that 2.7 is bug-for-bug compatible with 2.6? That everything in 2.6 is still in 2.7? Can you honestly see a Wall Street bank, a top-tier cancer hospital, or a world-class university blindly update to the newer version just cuz Python Project said so? And risk their systems _just_ _not_ _working_?
No? I didn't think so.
...because we don't want to rewrite all our software?
In today's lesson, we learn why it's generally considered a bad move to do a "clean break" upgrade in a FOSS project.
Corporations can get away with forcing developers and customers to upgrade (Apple does it all the time), but that's usually risky. Microsoft has been known to actually put bugs back into their OS in order to ensure compatibility.
FOSS projects can't get away with it. We have a whole set of infrastructure scripts written in Python that would need a pretty major overhaul to go Python 3. I think that they all run in 2.4 (I'll have to check).
If it gets to the point that we can't run them anymore, then we'll have to rewrite them.
In something other than Python.
I'm just going to mirror what this guy said. There's a reason why IE6 was still around *years* after it should have been taken out back and shot. There's a lot of money dumped into these project and applications. I'd make every effort to encourage a transition, but those cost money and time.
RHEL/CentOS isn't the only problem. There are versions of Ubuntu Server still in long-term support that still ship with outdated Python, such as Ubuntu 10.04 LTS that ships with Python 2.6. Another is the fact that some Python libraries use C modules (as opposed to using pure-Python code that uses ctypes to interact with shared libraries), and some users under Windows may not own a copy of the appropriate version of Visual Studio to recompile the module. For a long time, the official binaries of the MySQL database client module for Python for Windows didn't support anything newer than 2.5.
New Python versions come with incompatible changes. Very rarely you can grab code written for one version and run it completely unmodified on a newer version. This sucks and is made worse by third party APIs that also have to be modified.
It is hard to release new language versions and also keeping backward compatibility. Some languages do it better than others.
If it ain't broke don't fix it. I've run into that where a developer hoes to a new version of something and as a result what used to work fine now has problems. When the developer says 'I can fix that...' I tell them just to roll it back. Unless there is some new feature that makes upgrading useful there is no reason to run the risk of problems. Users don't care about the underlying technology as long as it gets the job done with a minimum of fuss.
I'm a consultant - I convert gibberish into cash-flow.
Why doesn't the new version of Python interpreter support older dialects ?
Still ships with 2.4
Rhel 6 not much newer.
Lot of us with lots of production boxes want stable and fight to keep it that way. There is also the library issue many have not ported to 3.x or made major we broke things changes to do so.
No sir I dont like it.
(source)
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
You could try porting your 2.4 scripts to 2.7, justifying it to your boss as a security measure to stay on a version of Python that will remain supported for the foreseeable future. That should involve very little change to your code. Then gradually shift the program to use those parts of Python 3 syntax that Python 2.7 supports through from __future__ statements, such as Unicode strings, print() as a function, and the like.
Why not?
Because some people can't upgrade to the latest and greatest for a variety of reasons. Tone down your arrogance - its messing up your nose hair.
It's possible to update without updating blindly. If the 2.5/2.6 version still passes unit tests and the most critical acceptance tests under 2.7, then perhaps 2.7 can be rolled out across part of the company at a time, using each division as an acceptance test for the next.
No really.
I took a pass at Python 3 a while back. The amount of hoops I needed to jump through, to deal with compilation errors around Unicode handling, was terrifying. It was simply a poor user experience.
Python 2.7 just works. Sure, it's a nightmare past a certain scale point. But until you get into the dregs of OO it really is executable pseudocode.
Python 3 is some other language that lost that property.
The big problem is that we don't ship languages with telemetry that reports when they fail to work. So things that are completely obvious to outsiders never make it to inner circles. Not that I can really see any way for Python 3 to mend its errors.
Also, to be realistic, you don't earn any money upgrading your existing software to the latest platform.
If you don't require features from Python 2.7, why drop support for older version?
It's all fine and dandy to switch over to a new version of python. But unless we can justify it to our client, it ain't gonna happen. The client just isn't going to go for it unless they see some measurable/provable benefit to switching. From their point of view it works, and we'd better damn well not touch it. Unfortunately, the codebase has grown over the years, and sloppy developers have come and gone, leaving the rest of us with a brittle codebase that has very little code-coverage. This is most certainly NOT an ideal scenario when it comes to upgrading, as there are too many unknowns. And that's assuming we could get the client's permission, because yes, the code belongs to them.
Congratulations, you were successful. If it isn't broke, hundreds of thousands of installations don't want to fix it.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
The appropriate question is: Why should I re-write/replace/upgrade my software, that works perfectly fine(!) because some developer of the Python project decided to refactor/deprecate a function/break a feature or otherwise fiddle with the system.
Any software that runs properly today, should continue running long into the future. If it doesn't, if the langauge developers break my software, they are the issue.
From a user perspective, there is nothing I hate more than some app that suddenly needs a completely different version of Java than the one I'm running! My app ran on Java 1.6.1 through 20, but suddenly on 21 forward it doesn't work? Java/Oracle broke my app and is forcing me onto an upgrade treadmill which I have no genuine need to be on.
This is what I call developer blindness. They feel that they know better and that users or other developers are stupid for not embracing the idea that wheelSpinNG() is vasly superior to the now deprecated wheelSpin(). For all the Microsoft hate that goes on around here, they have historically done a fantastic job at maintaining backward compatibility. You seem to want to fail it.
since the authors of python don't do proper unit and regression test and maintain backward compatibility, the 2.4, 2.5, 2.6 and 2.7 ARE DIFFERENT LANGUAGES! Its past time for open source wares (including the LInux kernel ABI) to get some maturity already in the realm of backwards compatibility, open source could go more places if it had that.
I think a large part of it is due to the convenience of Jython, which makes it really easy to embed Python directly into a Java application as a user scripting engine that doesn't require explicit installation or configuration by the user. I'd go so far as to say that Jython is probably 99% of the reason WHY so many Java apps that support scripting do it via Python instead of some other language.
Jython only supports 2.x syntax.
There IS a way to bind a Python interpreter to Java so it can exchange objects directly (py4j), but it still requires separate installation of Python, with all the usual things that can go wrong (and frequently do, at least under Windows), like environment variables, path definitions, etc.
There's also IronPython, which is another 2.x-only Python that enjoys lots of "automatic" mindshare from Windows developers because it presents itself as the "official Microsoft-blessed .Net CLR Python" for Windows, and everyone remembers that a decade ago, Activestate Perl was the de-facto Perl for anyone running Windows (and eventually, the defacto Perl, period). It's basically abandonware at this point, but ActiveState doesn't go out of its way to make it obvious.
That said, I'd put most of the blame/credit for 2.x on the non-existence of "Jython 3".
It's been over 5 years. Why are you still on the 2.x line? Why are NEW PROJECTS still being made for 2.x? Stop being complete asshats and FUCKING UPDATE!
Because the development staff are skilled and efficient with the 2.x line, but not the 3.x line. As such any new project will require an order of magnitude more time using the 3.x line, at a minimum.
Unless you can convince mgmt that it is a good thing to have all developers out for paid education for a week or series of weeks for a good class on all the new bits and pieces in 3.x, as well as all the 2.x pieces that are no longer supported in 3.x.
It all boils down to economics.. how much money are you willing to loose to get the next project done in 3.x.. for most companies.. that number is ZERO
Because Python is a scripting language, and you don't get to decide the interpreter version.
If you are upgrading Python without so much as reading about what 3.x is and how it's different from 2.x, you're probably not qualified to be handling such an upgrade.
3.x was explicitly declared as a new language with breaking changes all around, so as to get rid of legacy cruft. This information was widely disseminated through all official channels - documentation, mailing lists, changelogs etc - and carried over on unofficial ones, like textbooks. That's precisely why all Linux distros out there install 3.x and 2.x side by side, and don't treat one as an update to another.
If your Linux distro silently re-symlinked /usr/bin/python to python3 when you installed the latter, then your Linux distro is broken - you should complain to its maintainers. If you installed it manually, then you have only yourself to blame.
And, getting back on topic, this all has nothing to do with 2.6 -> 2.7 transition, where the language is the same and backwards-compatible.
Javascript is the language of the Internet!
And, if you've wrapped any of your c/c++ code in dll's, you'll have to recompile them for the new python version. :-|
Why doesn't the new version of Python interpreter support older dialects ?
This. This is the right question!
In visual effects and animation, many of the 2013 editions of animation applications that are scriptable (Maya, Nuke, Hiero, etc.) are still stuck on Python 2.6 (usually following Autodesk's lead). A few of the 2014 software editions now use Python 2.7, but studios rarely upgrade to the latest and greatest in the middle of a show. Lots of things can break, especially C++ plugins that might also be scriptable through a particular Python version.
It would probably have been less work to just change the default interpreter back to python 2.5, and edit only the 'one piece of software' that required python 3 to /usr/bin/python3
.. its still very early to migrate to a newer version.
Last couple of years I've worked at shops still using WebSphere 6.1 (JDK 1.5 = September 30, 2004).
My current project involves an application on the 'new' platform, WebSphere 7.0 (JDK 1.6 = December 11, 2006) for
a rather big bank (top 500).
Just my 2 cents,
Lau
a lot of applications have simply not been ported from python 2.7 to python 3.x
Python is dead end for MySQL database client module!
A Wall Street bank, a top-tier cancer hospital, or a world-class university would have upgraded to Python 3.x years ago. That's just what makes them the best. They don't wait for others to tell them what do to. They know what to do before anyone else does, and then they do it. That includes upgrading to Python 3.x early.
Here is our free whiz bang program....it just needs the half a dozen dependencies listed below, that will not all be maintained, and at least one will break the others regularly....you did want to spend your life as an unpaid programmer instead of working didn't you.
It's not complicated. It's simple. Upgrading a production system is a *big deal*, and in many places there is a long delay between updates. Enterprises will often pay big $$$ to NOT upgrade (other than security patches), because they want rock-solid stability much more than the latest hotness.
E.G., RHEL 5 and CentOS 5 are widely deployed, and will be used for some time to come as production systems. They only support older versions of Python2. Therefore, *useful* programs that need to run on these widely-used systems must be written to run on these older systems.
- David A. Wheeler (see my Secure Programming HOWTO)
Sounds like you did it wrong. Why didn't you just rename the binaries?
I was thinking about teaching my son Python as a first language, but after reading how often the maintainers break compatibility I can't be bothered now.
I must be getting old cuz I'm so sick to death of the perpetual bullshit changes in IT. I've had a gut full of having to refactor my code every time a new c++ standard comes out. And how often these days can you download a project from source which compiles and links cleanly without having to fuck around with fixing link errors with missing or changed symbols in dependent libraries which aren't the exact version it's expecting?
How much better is the experience browsing the web today using Firefox version 232 or whatever it's up to compared to the experience browsing the web in 1999 using Netscape? Fuck all I reckon.
I can't understand why people are saying Microsoft is so great at maintaining backward compatibility. I seem to recall just about every new version of Visual Basic broke compatibility. That was one of my pet hates which drove me to Linux. That and the fact Windows used to crash 20 times a day.
Versions of everything are ancient. They never upgrade their software, and they won't let users do anything that remotely resembles admin work, because hackers. I can't even change the appearance of my desktop icons. I don't even think they don't upgrade for fear of breaking something. More probably they're just lazy and incompetent and wouldn't even know how to upgrade, and the last person who knew has since left to start a bakery.
It has the same name, has tools to convert from one to the other, and near identical syntax; but lack of backwards compatibility makes it a new product
Trying to force people to migrate from one product to another always meets with massive amounts of inertia.
The problem with upgrades is the developers don't take nearly enough care to ensure compatibility with existing software. For instance, I moved a Python script from an older machine (redhat 9) to an Ubuntu 12 system with a later 2.x series Python, and the script immediately bombed out. Turned out that I'd used "as" as a variable name, and it had become a reserved word in the interim. Elsewhere, I was adding ints to floats or vice-versa; now that produces an error. Somewhere, the behavior of "global" changed. I had a procedure written with global VariableName up front so the procedure could see a global switch. I handed the script to someone else, and they had to *remove* that to make it work.
I moved a large system depending on perl scripts (yes, I know, not Python, but the issues are identical) across the same machine pair and it was so broken under the new perl that it took me two months (and cost my client a great deal of money) to adequately debug and update it. From external module changes (use DBI) to how references to hashes were handled, it was one thing after another. What made me fume the entire time is that this stuff worked *perfectly* under redhat 9 with the earlier perl -- it really wasn't broken. Bloody perl was broken! Worse, I'd abandoned Perl for Python years ago, and my Perl skills were very rusty... that's tough when you're trying to work through tens of thousands of lines of sophisticated code. I truly regret every line of Perl I ever wrote, and cringe at the idea of having to revisit it for any reason at all, because Perl, whatever its true merits, is a language that I was destined to hate to my very $core;
This kind of thing makes me extremely unwilling to upgrade; for that matter, it can send me hunting for the old version to install in new machines, although that can present its own set of problems and requires at least some of a different skill set than programming that really leans more into system administration, which I am not in the least enthused about. For some strange reason, enjoying research on auroras does not automatically carry with it a predilection for meddling with OS environments.
This is all part of a larger gripe set I have where makers of languages and APIs break existing code in favor of new ideas. Here's my position: If you ship the language with X features, you have NO BUSINESS breaking ANY of those features. You have a new idea? Fine. Implement it as something completely new within the language or the API. If it's got new keywords, provide the programmer a switch to enable them -- words that were not reserved before may have crept into the user's namespace(s.) Never take a call out of an API. Never make an API call work differently. If you think you need to do that, then *I* think you need an entirely new API. If you even use the word "deprecated", I will burn you in effigy and spit on the ashes. Furthermore, if you do it right, you will NEVER need to say "end of life" because the most current version will still run the first code ever written for API or language 1.0; upgrades will actually be upgrades rather than incompatible replacements.
Windows got this very nearly right for a long time, then with XP, they began to break everything from window metrics to system calls. By the time Windows 7 rolled around, apps that worked perfectly looked like trash and worked even worse, and I tossed my Windows machine in the can both for development and as a user. Apple's guilty of this too, even going so far as to obsolete their own applications and feature-sets. One really irritating example of this is having bought Aperture 1, 2, and 3 for OSX 10.6, I bought a new camera, a Canon EOS 6D. Works *fabulous*, pretty much the first DSLR I've ever been actually satisfied with. Both Lightroom and Aperture required an update to read the RAW images. Lightroom upgrade went smoothly. The Aperture upgrade? Told me that in order to install the updated RAW support, I'd have to upgrade the OS. But 10.7 and later are not highly compatible upgrades, I have to support OSX
I've fallen off your lawn, and I can't get up.
All these crappy python applications asume that /usr/bin/python is just the right version for them. /usr/bin/python2.7 ), and under the generic /usr/bin/python.
Both python 2.5 and python 3.0 install with a version number (e.g.
What did you want me to rename exactly? And why should I as a user need to rename stuff just because python developpers can't be bothered to use decent versioning?
Secure messaging: http://quickmsg.vreeken.net/
Bullshit.
All programs had '/usr/bin/python' set as their interpreter.
Some developpers asumed it would be python 2.5, the others assumed it would point to 3.0.
Why is it my fault (the user of a package) that python developpers make a mess of their versioning system?
They made a new and incompatible language and gave the interpreter the exact same name and you think I am not qualified??????
Secure messaging: http://quickmsg.vreeken.net/
Some environments and languages prioritize backwards compatibility above all else. Those systems tend not to have much trouble running old code. Sounds great, but over long stretches of time this can result in entire ecosystems of code and software that looks old, acts old, feels old, and has difficulty selling to customers.
Python, I think we can say, is not one of those.
OK, so any port, even a relatively easy one, involves opening the door to problems. That means a test cycle will be required. If your developers are ready and available this can be a small matter easily handled. However in many environments, once a system is delivered, it takes organizational support to begin changing it. No matter how small the change appears to be! If that support isn't there then forget it.
Some developers are given a relatively free hand and can take on projects just because they think the merits stand up. Other times the devs are on a short leash.
And we haven't even discussed matters of system size and complexity yet.
As I say, everything depends.
If only the one piece of software was just one executable....
Even then it was conversion work I as a user should not have to do.
Secure messaging: http://quickmsg.vreeken.net/
Why are we Python developers inflicting so much pain on ourselves to support antiquated Python releases?
If I were a Python developer, instead of Python user, and there was a lot of pain supporting old Pythons, I'd just stop supporting them (instead of whining.) Older versions of Python only receive bug fixes. People who are still using an older version evidently are happy with it, bugs included. So, Python developers should fix old bugs if it's painless, or not if it's painful.
About the only exception I can think of is security problems: if a security flaw in an old version is suddenly revealed, it should be fixed by Python developers if at all possible. Then again, if that becomes too much trouble for Python developers, they can just (politely) say "if this bug really is a problem for you, you should just pay the pain yourself by upgrading to a newer version where we've fixed it."
Another clear exception is that the last 2.x version, 2.7, should have its bugs fixed into the foreseeable future because so many of us still prefer 2.x. Then again, I would have already switched to 3.x if a 2.7 didn't (already and into the foreseeable future) work just fine for everything I need Python for.
Python has a well-defined versioning scheme for interpreters which is documented in detail. In particular, it requires that python2 is a symlink to some version of Python 2.x, and python3 is a symlink to some version of Python 3.x; authors of Python code should author their scripts correspondingly. If someone wrote a 3.x script that starts with #!/usr/bin/python, then they are the problem, and you should whack them with a stick until they fix that.
Also note that this spec requires that python be the same as python2 until further notice, which will happen in 2015 at its earliest. So, again, if you or your distro symlinks python to python3, then that distro is breaking things.
As a user of a package written in Python, you are, of course, not at fault. But it's not a fault of Python language & interpreter developers, either - as you can see, they were well aware of the problem, and came up with a working solution. They can't really help it if distros (which are, ultimately, responsible for installing Python on your system) don't follow that solution, or if app developers who use such distros write bad code.
It's easy for a Python programmer to choose an editor that also knows about whitespace. The rest are good enough that they don't even need to. Personally, given the choice between extraneous { } all over the place and indentation, I definitely prefer indentation. It's fast, it's highly visual, and it reduces display clutter.
I've fallen off your lawn, and I can't get up.
It's been over 5 years. Why are you still on the 2.x line? Why are NEW PROJECTS still being made for 2.x? Stop being complete asshats and FUCKING UPDATE!
Because the development staff are skilled and efficient with the 2.x line, but not the 3.x line. As such any new project will require an order of magnitude more time using the 3.x line, at a minimum.
Unless you can convince mgmt that it is a good thing to have all developers out for paid education for a week or series of weeks for a good class on all the new bits and pieces in 3.x, as well as all the 2.x pieces that are no longer supported in 3.x.
It all boils down to economics.. how much money are you willing to loose to get the next project done in 3.x.. for most companies.. that number is ZERO
Exactly. Because unlike the AC you replied to, who probably lives in his parents basement and codes for his own use and not things that have 1000s (or more) users that rely on them, he has no concept of budgets and time constraints. Employees of real companies that actually make profit$ know that the company exists (and their job exists) to earn money, not play around with upgrading to the latest and greatest incompatible 'upgrade' every time something new comes out, and potentially breaking things that other people in the company (or worse, clients) rely on to do *their* work. Their lost time means lost money (and in the case of clients, perhaps even lost business because you cost them money by messing with something that worked fine).
From The Zen of Python:
There should be one-- and preferably only one --obvious way to do it.
From TFS:
Nathan Froyd adds "I think this list of reasons to upgrade misses the larger point in providing software for other people: You do not get to tell your users what to do...."
This is one of the main reasons I hate Python: It's Guido's way or the highway. But, furthermore, Python 3.0 violates this principle as well: If there was one way to do it in 2.x, that way should continue to be the only way to do it in 3.0.
(T>t && O(n)--) == sqrt(666)
In that case, remove /usr/bin/python and replace it with a link to python2.7. Then change the one script that actually needed python30. Really not hard.
If you have one application that requires 3.0, and everything else is happy with 2.5, I would just link /usr/bin/python back to 2.5, and change the one program that doesnt work that way to call 3.0 explicitly, rather than changing ALL the other programs to call 2.5 explicitly. I assume that is what the GP meant.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Reason 1: Because I have a mission critical business app (not maintained by me) that runs on 2.x, so that's what's installed on my machine as the default. Of course I have 3.x too, but to use it I have to specify the version explicitly. It's extra hoops to jump through.
Reason 2: Because I mostly use python as a fancy scripting language. For product development or serious lifting I use C. I don't particularly care if my version is 2.x, if it ain't broke don't fix it.
Reason 2a: It's a flippin' scripting language. I don't want it to be more rigorous than it already is!
Reason 3: Everyone else at work relies on 2.6. Someone else is already supporting those 2.6 installations. If I make a project for 3.x, now I'm on the hook for getting everyone to install 3.x alongside their 2.x, I have to write docs, and when they have problems I have to handhold them through it. No thanks, I'll use what someone else is already supporting.
Reason 4: They are two different languages. I don't stop using C just because C++ and Java and C# exist. There is room on my system for multiple languages. Go ahead and develop whatever you want, but I will choose what I want to use. I have no obligation to learn a new language just because it makes you happy. You're the one who moved to a new sandbox, don't whine if others choose not to join you there.
Reason 5: Python 3 is similar enough to be confusing, but different enough to be aggravating. Really I just don't care enough. I think I'd rather move to a whole new language than wrestle the moving-target anaconda.
Pointing out the obvious: I update my python code to 2.7. Meanwhile, our giant contracted system that it don't manage runs only on 2.6. That is all.
Why didn't numb nuts just grep and sed and fix the problem with one command line and a RETURN key? Because he doesn't know what he's doing!
How good is a language when they must reinvent it for every major release? Python is a scourge. Use scheme.
Is the Python mafia modding tonight? That's an opinion, complete with a solid point to make.
Python has a well-defined versioning scheme for interpreters which is documented in detail. In particular, it requires that python2 is a symlink to some version of Python 2.x, and python3 is a symlink to some version of Python 3.x; authors of Python code should author their scripts correspondingly. If someone wrote a 3.x script that starts with #!/usr/bin/python, then they are the problem, and you should whack them with a stick until they fix that.
Also note that this spec requires that python be the same as python2 until further notice, which will happen in 2015 at its earliest. So, again, if you or your distro symlinks python to python3, then that distro is breaking things.
As a user of a package written in Python, you are, of course, not at fault. But it's not a fault of Python language & interpreter developers, either - as you can see, they were well aware of the problem, and came up with a working solution. They can't really help it if distros (which are, ultimately, responsible for installing Python on your system) don't follow that solution, or if app developers who use such distros write bad code.
Of course, that link you gave says: Created: 02-Mar-2011
So prior to 02-Mar-2011, people using say python 2.5.2 (released in 2008) were not being "informed" to write their code using /usr/bin/python2, and so all that old code is now "improper" according to a spec released *3 years* after the code was written. No, while one might argue that won't change until "2015 at the earliest", it is still quite possible that code might well exist that uses /usr/bin/python expecting (and only working with) python2. In which case, one might ask - if the new 'standard' (post 02-Mar-2011) is to use /usr/bin/python3, why would the symlink *ever* change (2015 or after even)?
So prior to 02-Mar-2011, people using say python 2.5.2 (released in 2008) were not being "informed" to write their code using /usr/bin/python2, and so all that old code is now "improper" according to a spec released *3 years* after the code was written.
Any code written prior to the release of that PEP would be using #!/usr/bin/python, and the spec requires it to be a synonym for python2 for now, and at least for 2 more years (realistically, that change is probably going to be postponed for much longer). So someone using Python 2.5.2 in 2008, assuming they wrote the proper shebang, and assuming that the distro (which has no excuse for not following the PEP today) did things properly, will work fine.
The problem that OP described was someone writing a script that requires Python 3.x, but using #!/usr/bin/python. Now I'll grant you that 3.0 was released in 2009, before the PEP, so there is some possibility that someone had a valid excuse - but in practice, given the slow uptake of 3.x, it is extremely unlikely that you'd run into a package that was originally written for 3.0 but not 2.7, and that hasn't since been updated for 3.1+.
In any case, the symlinks are implemented by a particular distro. If that distro follows the PEP, then it's the job of package maintainers to ensure that the packages they provide have the corresponding shebangs. If the distro doesn't follow the PEP and do silly things like symlinking python to python3, then it's also their responsibility to ensure that any packaged Python software uses shebangs that match their convention (by patching the sources if necessary).
Also, note that the PEP basically documented what well-behaved distros were doing since the release of 3.0. It's not really a long one, and that's because what it says is basic common sense.
In which case, one might ask - if the new 'standard' (post 02-Mar-2011) is to use /usr/bin/python3, why would the symlink *ever* change (2015 or after even)?
The idea with that PEP is that apps should try to be specific about the version of Python that they want, but that "python" with no version specifier should be whatever is the most convenient to the user, which, at some point in 3.x adoption, would become 3.x rather than 2.x. Ideally it should have been unspecified from the get go, but because there was no clear versioning scheme for binaries before that, we're stuck with python==python2 until Python 2.x dies completely. The 2015 date is obviously overly optimistic, but then that's why it's not a hard date, just an estimate. Still, at some point, 2.x will not be in use anywhere, and then we can change the link. Apps should still use python3, though, on the grounds that there may be a python4 eventually.
Speaking as someone who has just spent two days unsuccessfully trying to compile firefox, I am impressed to the point of apoplexy.
Forgive me for pointing this out, I know I am an asshole for putting it this way, but as the others have essentially pointed out, " upgrading " /usr/bin/python outside of what the distro does for you is a bone headed mistake . You are free to install anything you want wholly within /opt or /usr/local and be guaranteed that in so doing you can't in any way break the OS or anything properly written to work with the OS. Most distros, or at least addon repos, have sanely designed packages like python2.4, python2, python3, etc, that can be freely added without breaking anything existing. The most they will put in /usr/bin is a symlink of python3 to wherever the newly instealled python3 binary is.
Your prima donna "piece of software" that demanded python3, without giving you a side load of same so you would have no difficulties, is amateur crap, but it's easily fixed. Just edit the shebang lines of all the python scripts and change "python" to either the python3 symlink or the python3 binary.
P.S. - don't think I would ever claim that I have never made bone headed mistakes in my life, even in IT work. We all do; getting them corrected is how we learn.
At my last job I was working with FreeBSD circa 2000 and greatly appreciated anything I could find that worked.
Old ass version of python was why I ditched Gentoo.
So yeah, keep supporting/requiring those ancient versions of python, I'll just dump your ass and find something newer.
Then there was the fact the developer fuckers were spending more time bitching about netiquette like top posting replies on their mailing list than they were actually coding.
So um fuck Gentoo and fuck ancient versions of python, I have better things to do with my life.
I bet your idiot developers just expect gcc to be version 3.2 as well instead of checking what fucking version they are using.
Also, find me a distro that defaults python to python3. I dare you.
Extensive ergonomic testing shows the pedals are in the wrong order. So we're putting the accelerator on the left side on all new models.
Perhaps the exalted developers should have some respect for the users and stop breaking their programs. Yes, it's hard to make changes that don't break existing code. That's what separates the professionals from the amateurs.
why would you not use virtualenvs? I would never touch/use/do anything to the system installed python, anything I do is in a specific virtualenv with whatever version of python and assorted packages is needed, same thing with the system perl and perlbrew
-- the cake is a lie
I can always equate this debate to vegan v. meat. Why the fuck do vegans always have to make everything "taste like" something else. If it's so good wouldn't it be good on it's own merits? "Well it's almost like burger." No it's not. That's what Python v. C is. If it was so good it could stand on it's own merits, have it's own uniqueness other than, "Oh look, we can use indentation now instead of semicolons." Who gives a fuck? Really? All those semicolons over the years gave you carpal tunnel? I can tell you it's because you never left you parents basement, and it's not from typing. Again we are back to the "meat" of the situation, it's not the same thing. Alright, alright I got a little off topic there. If you are going to talk about versions of the the "meatless" variety, let me just say it's like an old girlfriend, sometimes you will upgrade and say, "How could I have ever been with 2.4!?", and sometimes it's like, "3.0 is my wife, but there will never be another 2.4, aahhhhhh yeah, what's that honey? I said Neville will be joining me for 2 pints at 4(p)!"
If they stuck to good old FORTRAN 4, there wouldn't be these problems
None of that newfangled FORTRAN 77 stuff with array indices that don't start at 1, and free format input/output instead of using FORMAT statements like God intended.
I've never bothered about environment variables for it and it always seems to find the correct library some long as they are all on the library path. The DLL hell problem didn't even exist on linux before the first line of python was written.
Every time I have a problem with Python, or something in it doesn't fit an existing and established workflow, or set of tools, the response is the same: "Why are you stupidly having requirements which we did not consider important in making our decisions?" I'm still expected to support some of the stuff I maintain for RHEL 5. Initial release, 2007. Therefore, Python 2.5 is the newest version that they could possibly have selected. And upgrading from one version of Python to another is not guaranteed to be stable. So anything I'm doing that has to run on RHEL 5 has to run on Python 2.5...
And that's really nothing particularly horrible. Many coding standards still aren't entirely comfortable with reliance on features introduced in C99, let alone C11.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Why don't people replace their video card and CPU every 6 months? There are costs associated with those things, sure, but it only takes a small amount of work to pop open your case and drop in the new hardware and the reality is that you WILL save time and energy from each and every small improvement: you'll spend less time waiting for the PC to boot, etc, etc.
Why don't people upgrade from Windows XP to Windows 7?
Why hasn't Python committed all-out to 3?
There are two main groups of Python users who are not going to upgrade:
. Users who consume installed Python software, who can only be negatively impacted by upgrading Python because they have no recourse to fix the stupid crazy crap that goes wrong when you upgrade Python without being Pyknowing. Historically many users experience with Python is that it's the thing that suddenly starts generating errors when they do an update on their linux distro.
. Users who have a large established based of Python code, which amounts to time and money expended on the Python version that works with their code, for these folks upgrading is largely frivolous when you consider the costs of re-testing and proving their source code, or the cost-risks of deploying it if they don't have sufficient testing infrastructure.
The latter group have two paths they could take: Python 2.x, which is generally a "deprecated path"; upgrading to 2.x is basically busywork. Meanwhile, Python 3.0 is a pipe dream. Nobody wants to upgrade to Python 3.0 because the only people who believe in it are Pyvangelists. I don't mean Python 3's goals, I mean the Python 3 effort. It's a failure. It's not going to happen, people are too burned on it, it's been dragged out for 5 years. It's about as interesting to a company's bottom line as investing in Perl 6.
-- A change is as good as a reboot.
In this situation, you should'nt be installing your Python app in the first place. What if running your app causes something to go wrong?
Red Hat Enterprise Linux (and, therefore, CentOS, Scientific Linux, etc.) 6, which is the current version of the OS, comes with python 2.6. Version 5 of the OS, which is still supported, comes with python 2.4 and an optional python26 package, which installs python 2.6 in parallel with the default version. I assume that similar things are true for other long term support distributions.
In these distributions, using python 2.7 would require building it yourself and install it in parallel with the system-supplied version. This would add to the porting problems, that others have mentioned, the cost of maintaining python yourself. Thus, until these distributions update python to version 2.7, it is good that project maintainers provide support for these older versions.
Wikipedia:If it ain't broke, don't fix it
He said "deliver an up-to-date side-by-side version of Python" not "swap out the version that came with the system".
Projects introduce gratuitous change too fast. Developers can't keep up with it. Python 3 and Perl 6 are the best examples: The development world has mostly ignored them. Even minor versions come out too fast. I couldn't even tell you the difference between Python 2.3, 2.4, 2.5, 2.6, and 2.7 because my job isn't to keep up with Python minutiae. I use a dozen different languages, and the rate of change is just to fast to keep up. In the real world, you have to stick to a reasonable subset of a language's features and write code. C++11 is great, until you have to use an old cross-compiler that's stuck in 1998 on your code. Java 6 is great, until you have to deploy your software on an platform that's stuck on Java 5, or 4, or whatever. (I haven't even looked at Java 7 yet, and now there's Java 8 coming out. Too much change too fast. C++14 is DOA.)
The continuous removal of useful features is being done to make the developers' lives easier, not mine. My life only gets more difficult each time I need to do research and work merely to restore a basic feature which is now missing -- AND it usually ends up half-assed compared to the original feature. Similarly, the continuous changing and dumbing-down of the interface is being done to appease the developers and project managers, certainly not me.
Turn it around and ask --- what are the programming languages / environments which have been:
- stable
- usable
- useful
over a long haul?
What advantages does Python afford over such?
Sphinx of black quartz, judge my vow.
Aww the Python toddlers just discovered something the Java guys understood in the 90's. Namely you need to retain backward compatibility to ease transitions forward into new versions. Nice to see you cought up finally.
I am so sick of everything wanting to upgrade all of the time.
FFS my phone wants to constantly update a ton of crap that I'm not even interested in using, Occasionally I let it upgrade and it asks me to agree to some BS user agreement at which point I say no, fuck Samsung, why the fuck should I agree to some BS to use my phone?
Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
Ever wondered about what came before 6? Think about it for more than two seconds then tender your apology.
The "long term" was there to point out an old problem and avoid offending even the thinnest skinned of current programmers.
At one time it was BASIC, then it was almost a copy of Pascal, and it ended up looking like Java. Long term means ancient history in programming.
I don't know much about python 3.x - looks like they broke the string library and after that I stopped reading
As per this incisive blog post from the end of last year (i.e. just under a fortnight ago):
http://alexgaynor.net/2013/dec/30/about-python-3/
Liam P. ~ "Intelligence is a lethal mutation." (me)
He shouldnt have to do anything you fucking moron. No one should have to waste time renaming/repointing/grepping to work around what is essentially a bug with Python versioning. They devs of Python should fix their shit rather than give workarounds.
We have a product that runs an old Python rev. The reason we are stuck on it is a critical part of the program relies on a feature provided by a 3rd party OSS library that doesn't work on the newer versions at all. It involved severe hackage that we didn't discover was used until the programmer was long gone - it always "just worked as spec'ed" so we never asked how - our bad but that's history now. Since then we've discover the hack is simply impossible to duplicate at all - we did create a work-around that involved going to a system call but it's not portable enough to generalize. We're planning to re-write the app in another language that supports the necessary feature more directly and simply instead.
I just did a hack yesterday. One of our websites was running on perl CGI, and someone(s), years ago, inanely decided that they should write the logfile in cgi-bin. Now, selinux was extremely unhappy about that, so I moved the actual logfiles to /var/log/httpd, and made a symlink from the cgi-bin, and selinux is happy.
Why is this relevant?
Because, apparantly there are a number of perl cgi scripts for that website, and multiple places they write to the log from, and all of it's hard-coded, and one guy is (barely) starting to pick up, and we don't have a team to fix it. Budget for that? Hah. Hah. Hah.
And this is true of most of the places I've worked for decades. Someone write out of college, who barely knows what error handling is, whose largest program was a few thousand lines, and has zero responsibility, either job-politically, or monetarily, to assre that WHAT IS RUNNING BETTER KEEP RUNNING, complaining about "why doesn't everybody update to the latestgreatestwhizbang!!!" can and should be ignored, unless you feel like explaining the facts of life to them.
Hell, I'm trying (volunteering my time) to install some library software for an organization I belong to, and that's what it wants... and we're running an enterprise o/s (CentOS, since you ask), which doesn't *begin* to have the most current kernel, much less the versions of the utilities they want... having apparently built on the LATEST STUFF....
I'd love to see all developers forced to test their own software on a computer one to two generations old, on a stable o/s, and *not* inside the organizational network.....
mark
They didn't broke it, they fixed it. It had the side effect of breaking everyone who misused strings or didn't understand that ASCII is not the only text encoding out there, hence why you see a lot of flaming around.
Yes, I know all about FORTRAN's longevity, and the stupidity of companies ignoring or short-shifting legacy. The company is out of business, now.
Bull. Python is the one thinking "ASCII is the only text encoding out there"
Anybody actually paying attention in 2.0 would have changed the default encoding to UTF-8 with non-exception-throwing handling of errors (ie turning them into characters). The fact that a byte stream with any bytes with the high bit set will throw an exception at quite unexpected times and doing the most trivial thing (such as comparing to a "unicode" string constant) is bad and entirely due to Theo's insistence that ASCII is the only thing that exists.
3.0 is marginally better in that it appears to at least acknowledge that UTF-8 exists, but makes a lot of other things worse. In particular now you cannot do any text manipulation without first doing something to detect UTF-8 encoding errors. I can't even search for an 'A' which 2.0 allowed me to do.
This is a disgusting mess. And there is some problem with text in that it causes otherwise brilliant people, such as Theo, to turn into complete morons. I think the problem is that too many people's first interesting piece of software was learning "you can capitalize by doing string[n] = string[n] + 'A' - 'a'". This has then perpetuated the idea that somehow a "character" is important, that you must be able to get a "character" from any integer index, and that they can be substituted for each other. Try using english words (which are much more useful to humans than "characters") and you will see how pointless these assumptions are. I can assure you that software has managed to work with words, doing complex stuff like formatting them into paragraphs without losing a single one or breaking it in the middle, without these limitations. The same applies to "characters".
I can't even search for an 'A' which 2.0 allowed me to do.
But you can:
By the way, who is Theo (you've mentioned this name more than once already)? Do you mean Guido?
That's purely a matter for the packagers.
That syntax for the quoted string does not work for UTF-8, and requiring the b for the find argument is broken because I cannot reuse code.
Here is what I want (though I would prefer that 'b' be automatic and 'u' mean you want a "unicode" thing):
s = b'fooæbar\x88\n'
s now contains the UTF-8 encoding of æ and a newline at the end and also an invalid bit of UTF-8 in a byte with the value 0x88.
s.find('a')
s.find('\x88')
These work to find the byte offset of the given match
s.find('æ')
This is a search for a 2-byte string containing the UTF-8 of æ.
Yes I meant Guido, not Theo. Sorry.
Right, b'...' only allows for ASCII. I have to say though that using UTF-8 in literals, or really anywhere in the source code, is generally rather frowned upon (not just in Python). But if you want to, you can still do something like 'fooæbar\x88\n'.encode('utf-8').
The fact that bytes.find takes bytes, and str.find takes str, seems logical to me. Code that wants to deal with either bytes or str completely transparently and uses a literal (rather than accepting both the string and the substring as parameters, in which case the caller will provide matching types), should not be common. But you can still do it where you need it.
In particular, if - according to your overall argument that strings should really just be treated as byte arrays - you always want substring to be based on byte values, then you can do type checks for any parameters that you receive, and if it's str, decode it to bytes.
you can still do something like 'fooæbar\x88\n'.encode('utf-8').
That does not work as it will turn the \x88 into a two-byte encoding of U+0088.
I understand that bytes.find() takes bytes and that bytes.find('foo') is an error. However having to add/remove the 'b' as code is reused it rather painful, and makes duck typing a lot more unpredictable. In addition it sounds like I cannot put unicode (such as '\u1234') into a bytes constant, making portability even more annoying as I have to hand-encode it into UTF-8 (having had to do this for Windows C source code I can tell you that is very error-prone).
Although based on Python2.x, our C++ code with a Python api does exactly what you propose. All string arguments are examined and if they are what Python calls "unicode" rather than string/bytes then our own converter to UTF-8 is run. All strings returned to Python are using the "bytes" type (which is the same as str in 2.x). The main problem is that this return type will fail in Python3.0 as it is not automatically converted to Unicode, and we cannot convert to Unicode as we need to be able to return invalid UTF-8.
It would probably have been less work to just change the default interpreter back to python 2.5, and edit only the 'one piece of software' that required python 3 to /usr/bin/python3
The second bit wouldn't even be necessary - as far as I'm aware, the only distro that made python3 the default was Arch. Because python2 is still the default on most systems and incompatible with python3, most programmers working in Python 3 explicitly specify python3 in the shebang. (Using /usr/bin/python only is considered poor practice for this exact reason.)
Most human behaviour can be explained in terms of identity.
There were a lot of 'intermediate' standards in the interim where pieces of the C++ standards or TR1 were implemented, but not the whole document, leading to either earlier or later versions having ABI or API changes which may've broke code developed in the interim.
I have some 1995 era C++ code for instance, which was pre-namespace and used templates, which has been a nightmare to attempt to refactor.
Additionally there are other minor issues such as the changes to libc and libc++ headers such as the latter no longer including the 'equivalent' C headers by default.
Lots of minor changes over years can lead to lots of major changes when you get around to attempting compilation or porting of 'legacy' code.
Gentoo has supported slotted python for at least the past 3+ years.
While they've currently dropped everything older than 2.6, it had been possible to install at least 2.4+ slotted and have every gentoo python package available cross-compiled for every version of python on which it could successfully run.
Not to say there weren't some hiccups back in the python 3.0 days, but that was what... 4-5 years ago now?
I worked lately on a project using Python. I initially used Python3.x.
I had to revert from Python 3.x to Python 2.x (perhaps 2.75), because some module/libraries were not available (ported) to Python 3.x
Pyserial (and a few more) worked, but several modules were not available.
So a push to port as many modules possible to Python3 is the way to full adoption !
As simple as this.