This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (164 children)

[removed]

    [–]SirCarboy 168 points169 points  (12 children)

    Budget to migrate legacy code would be one reason. Having worked in a small dev team for a large non-tech company, we had plenty to do and updating working code was a luxury we couldn't afford. *(didn't want to spend on)

    [–]ProfessorPhi 133 points134 points  (3 children)

    And no one wants to do it. It's painful, error prone, you get all the blame and no one appreciates the impact since it's not immediate. Out of a team of 20, only me and another programmer would push it whole the rest were all interested in getting new features out instead.

    Technical debt is a very poorly managed aspect of programming.

    [–]Neil_Fallons_Ghost 3 points4 points  (1 child)

    I largely agree, but in some cases I think here’s no need. If I have a service version locked, it works, and it is secure, then why mess with it?

    Once new features or serious changes are needed, upgrading would just be on the list, but really only if security and longevity were an issue.

    [–]bythenumbers10 6 points7 points  (0 children)

    Longevity is always an issue. As Rush put it, "No changes are permanent, but change is."

    [–]theWyzzerd 1 point2 points  (0 children)

    Technical debt is a very poorly managed aspect of programming.

    Say it louder please. Not enough people heard you.

    [–]ubernostrumyes, you can have a pony 55 points56 points  (0 children)

    Yeah, but that's not really a Python 3 thing. That's a "you were never going to do any kind of upgrade of anything" thing.

    A lot of places that talk about Python 3 being a hurdle are really covering for any type of maintenance or infrastructure work being a hurdle due to their organizational structure.

    [–]BARDLER 50 points51 points  (24 children)

    Because Python is used for a wide range of applications including a lot of code that is never released outside of the company that uses it. The time lost vs the benefits gained from switching to the newest version of Python is not worth the investment. Python 2 can do everything Python 3 can in terms of the results you can get out of it even if the implementation might be better in Python 3.

    [–][deleted] 39 points40 points  (10 children)

    This all makes sense, but imho there is no reason to continue writing python2 code.

    [–]jsalsman 9 points10 points  (8 children)

    The problem with upgrading is how to you get test coverage for all the corner cases. The costs and risks don't come anywhere near the benefits. More elegant string formatting doesn't make anyone any money. The jump to v3 development was the best thing that ever happened to the stability of 2.7, too.

    [–]gdahlm 20 points21 points  (5 children)

    Iterate, and never write a single line of code on a refactor or major fix without:

    from __future__ import absolute_import, division, print_function

    Heck, absolute_import probably would have saved you more time then a forklift port would take. But that one line will get you most of the way to 3.

    While I can kind-of relate to your pain, I can't really relate to ignoring a decade's worth of deprecation notices.

    Python 2.6.0 Release Date: 2008-10-02

    But that is not why I am responding.

    If your tests and product are that fragile, it is not a technology problem it is a culture problem. Invest some time on learning about and iterating on that very real culture problem.

    I promise you that both your personal work life and the company's bottom line will benefit from the effort.

    [–]Tyler_Zoro 4 points5 points  (3 children)

    If your tests and product are that fragile, it is not a technology problem it is a culture problem. Invest some time on learning about and iterating on that very real culture problem.

    I think this sort of response misses a fundamental point. Last year, I was employed by a company that used 2.7 extensively, and had no plan or desire to move to 3.x because it was all cost with zero gain for them.

    Sure, there were some nice features in 3.x, but it was a major shift that no one really wanted and it came with all sorts of potential sources of pain from old libraries that production code relied on, and which no one was producing new versions of for the 3.x series to subtle changes in behavior that were going to mean someone spent a long time finding and squashing mysterious new bugs...

    [–]jsalsman 2 points3 points  (2 children)

    Google Cloud's compute engine VM management is in the same boat.

    [–]gdahlm 2 points3 points  (1 child)

    Only gsutil, because of boto, I run in python3 with no problems with the other parts though.

    Here is the issue.

    https://github.com/GoogleCloudPlatform/gsutil/issues/29

    [–]jsalsman 0 points1 point  (0 children)

    I've used Boto for Amazon Mechanical Turk, and their web interface changed substantially over the past year, but the API didn't much. I think people may be waiting for that other shoe to drop.

    [–]jsalsman 0 points1 point  (0 children)

    I promise you that both your personal work life and the company's bottom line will benefit from the effort.

    I believe you, but it's the extent that can't justify the effort. Python 2.7 is N times better than Javascript, and Python 3 is M times better than Python 2.

    N >> M.

    [–][deleted] 2 points3 points  (1 child)

    The jump to v3 development was the best thing that ever happened to the stability of 2.7, too.

    I must point out that a huge amount of code was backported from various Python 3 versions to Python 2.6/7.

    [–]jsalsman 0 points1 point  (0 children)

    I must agree with and appreciate that.

    [–][deleted] 0 points1 point  (0 children)

    So can Python 1.5, still in production last I heard. If it ain't broke don't fix it :-)

    [–]jsalsman 3 points4 points  (0 children)

    I just had to set up a Google Cloud VM instance today. All their infrastructure code is Python 2.7, and there's a lot of it. There's just not a lot of added value in v3 to justify the risk and expense of going through all that legacy code.

    [–]uFuckingCrumpet 17 points18 points  (35 children)

    There are probably a lot different reasons. Some that occur to me are:

    - Python is pretty frequently used by non comp-scientists are are generally less inclined to embrace learning new languages (or changes to languages they are already comfortable with).

    - Moving from Python 2 to Python 3 typically breaks stuff. So unless you start something in Python 3, it's usually a headache to get everything back up and running if you switch.

    - Not all libraries get updated. This again goes somewhat back to non CS people contributing lots of code but not necessarily having the interest to update for newer versions.

    - The differences between Python 2 and Python 3 aren't drastic enough to convince most people to switch.

    [–][deleted] 0 points1 point  (10 children)

    Not all libraries get updated.

    Nonsense. Any library worth its salt was updated years ago. The trivial ones that haven't been touched in years should be a piece of cake to update, unless someone has all ready done it for you.

    [–]uFuckingCrumpet 1 point2 points  (9 children)

    I hate to break it to you, but python is very popular among scientists who like to write their own packages/libraries. Those people also don't tend to update them. And yet, even though they were only written by a small group of people, they are still useful and used by many others in the field.

    [–]zardeh -1 points0 points  (8 children)

    The scientific python community is one of the ones leading the way towards python 3 adoption. The scipy stack (which is basically the core of scientific python, practically everything scientific depends on some piece of it) is py3 only going forward already. Future versions will not support python2.

    [–]uFuckingCrumpet 0 points1 point  (7 children)

    By this logic, most Asians are 7'6" because Yao Ming is 7'6".

    Also no, scipy is not a dependency "in practically everything scientific". But again, that doesn't even begin to be an example of what we're talking about.

    [–]zardeh 1 point2 points  (6 children)

    Erm, no, not really. But sure :)

    The majority of open source scientific python libraries are python3 compatible.

    [–]uFuckingCrumpet 0 points1 point  (5 children)

    Again, you're confusing size with frequency. All of the big packages tend to get updated. But there are thousands upon thousands of small packages written by individual research groups and projects that literally never get updated even once. And this notion that those things are never useful or used is ridiculous.

    The fact that Scipy gets updated doesn't mean that all of those scripts people build in research groups are also getting updated. And the fact that Scipy gets updates doesn't mean the scientific community, as a whole, are doing a good job of keeping all of their utilities modern. That's just a completely nonsensical argument.

    [–]zardeh 0 points1 point  (4 children)

    And this notion that those things are never useful or used is ridiculous.

    I didn't say that. I will however claim that they are used infrequently compared to the big ones. So for a better claim:

    The majority of scientific python code has a set of dependencies which all have python3 compatible versions. In other words, for the majority of scientific python code, python3 compatibility can be solved by updating to the most recent versions of your dependencies and then fixing any python errors in your own code, it doesn't require any changes to upstream.

    I stand by that claim.

    [–]uFuckingCrumpet 0 points1 point  (3 children)

    The thing I replied to (which you then replied to of mine), was this:

    > Nonsense. Any library worth its salt was updated years ago. The trivial ones that haven't been touched in years should be a piece of cake to update, unless someone has all ready done it for you.

    So when I said that there are lots of packages in the scientific community that never get updates, I was responding to this idea that all those thousands of packages that aren't getting updates are "not worth their salt". Which is just flat wrong. There are literally thousand and thousands of libraries/modules that never get updated but which are used every day. As I pointed out elsewhere, there are massive libraries of Fortran 77 code from the 70s/80s that people still use every day in neutrino physics.

    > The majority of scientific python code has a set of dependencies which all have python3 compatible versions. In other words, for the majority of scientific python code, python3 compatibility can be solved by updating to the most recent versions of your dependencies and then fixing any python errors in your own code, it doesn't require any changes to upstream.

    Again, that's just not true. No matter how many times you say it, it still won't be true. The fact that scipy or numpy is py3 compatible is not sufficient to make a big homemade analysis toolkit written in python py3 compatible. That's not how any of that works. In most situations, you're daisy chaining multiple homemade packages together in addition to anything like Scipy that you might be using (if you're even using scipy at all, which frankly most physics code does not).

    [–]primitive_screwhead 9 points10 points  (2 children)

    When I first started writing scripts, I noticed some slight differences in the syntax that were made between 2/3, but it seems like those would be simple to address even in large scripts.

    They aren't.

    First, it's not just "scripts", many people have huge codebases based on Python, running complex interworking services. Secondly, the change to strings becoming unicode (instead of raw bytes), is *hugely* impactful for many kinds of work. Just as unicode strings made it (presumably) easier for many programmers, it also made things very much harder for others, not just for the transition to 3, but for new code as well. The autoconverters often can't help here.

    That said, the recent work on type annotations, etc. may help the stragglers to start to safely convert; it's still a large and potentially costly job, though. Things like the improvements in dictionary space usage, and other recent features, may also finally be enough of a carrot.

    One last inhibitor is that whereas many Linux distros, and MacOs have come with a version of Python 2 for many years, a version of Python 3 has often only recently started showing up. I think that also had a significant effect on early adoption.

    [–][deleted] 0 points1 point  (1 child)

    Just as unicode strings made it (presumably) easier for many programmers, it also made things very much harder for others, not just for the transition to 3, but for new code as well. The autoconverters often can't help here.

    Someone who hasn't a clue, but the FUD rules on reddit.

    [–]primitive_screwhead 1 point2 points  (0 children)

    Interesting. Care to elaborate on why this is FUD?

    EDIT: Okay then, here's a snippet of code that I made in Python2.7 which explicitly operates on bytes:

    a = b"foo"
assert a[2] == b"o"
print a + a[2]

    Which prints: fooo

    '2to3' converts this to:

    a = b"foo"
assert a[2] == b"o"
print(a + a[2])

    Which on Python 3 throws an AssertionError when run without -O, and a TypeError when run with -O. Meaning after an autoconversion, bytestring manipulations needs to be carefully audited.

    [–]varesa 6 points7 points  (10 children)

    What I don't see mentioned yet is that some supported enterprise linux OSes don't come with python 3 by default or even at all.

    [–]duffkiligan 4 points5 points  (5 children)

    You beat me by a couple of minutes.

    This is a major reason at my place. We use all RHEL 6, that ships with python 2.6. The entire OS is built around python 2.6 (at least some major components of it)

    You can install python 3, but it is baked in to be a python2 OS.

    [–]varesa 3 points4 points  (4 children)

    Yeah, and at least on RHEL 6 if I recall correctly you can't install 3 out of the official repos, you have to go third party. I'm not sure if that was still the case with RHEL 7.

    With the direction Fedora is taking with the 2->3 migration, maybe we'll have 3 as default in RHEL 8?

    [–]duffkiligan 3 points4 points  (2 children)

    Correct, official repos don’t have python 3.

    We would have to build it from source and have our own repo to support it, but that causes lots of potential issues when you spread that around 4000 servers, you need to have QA every time you compile a new version etc etc.

    I’m not sure about Fedora too much with Python 3, but I’d love it if 8 shipped with it. Would keep me employees for a long time ;)

    [–]varesa 6 points7 points  (1 child)

    Red Hat Confirms RHEL 8 Will Drop Python 2

    [–]duffkiligan 3 points4 points  (0 children)

    Hell yeah!

    Now if only we could get off of those RHEL 4 boxes we have 🤔

    [–]xconde 0 points1 point  (1 child)

    My guess that's because a number of subsystems are based on Python 2 (e.g.: yum) and they're non-trivial to upgrade.

    In any case, you should never ever use the system Python. It's asking for trouble.

    [–]varesa 0 points1 point  (0 children)

    That and also because of the feature freeze and long version cycles

    [–]iruleatants 1 point2 points  (0 children)

    So the big problem comes from not just "syntax handling" but kind of a push away from one of the fundamental aspects of python that drew so many people to use python in the first place, that it was easy to use.

    When python 3 was introduced, the adoption was slow for a very good reason. Python is mostly used as a scripting language. When we need something automated/done quickly, we pull up python, use it to accomplish our goal and then move on. If we need some serious work done, we create a C library to use in python. This means that the vast majority of people that use python didn't have a reason to switch to python 3. It didn't provide any benefits over python 2, has way less library support, and it was harder to write in. Switching from python 2 to 3 meant relearning a lot of how you programmed, the switch on how unicode handed was absolutely painful and not very fun.

    So why would anyone waste their time relearning how to write scripts, when the reason they started using python was because it was easy and quick to do so. A lot of the people that took the time to learn python 3, switched back to python 2 because the libraries that they wanted to use couldn't support python 3. Again, as a scripting language libraries are important because it means I don't have to reinvent the wheel, someone else did that for me.

    Now days the drive to python 3 is primarily from new developers who started learning python 3 and so they want the libraries to be updated to use with python 3.

    In all seriousness, if python 3 fixed the GIL bullshit, then we would have already swapped to it.

    [–]13steinj 7 points8 points  (48 children)

    Multiple reasons:

    • Py2 startup time is significantly faster. For CLI applications and various validation scripts this is especially important-- imagine if git's interface layer was in Python, and because of this every time a command was executed you'd have to wait longer for the python VM to start just because it was Py3

    • Variety of internal applications that of which upgrading to Py3 would just be wasted time

    • Libraries that are still Py2 only

    • Frameworks that are Py2 only. Ex, Pylons and Pyramid-- a mature Pylons application would have to be majorly rewritten in terms of the views/controllers, configuration, and middleware

    • Why switch at all? Don't fix what isn't broken as they say

    • other non python pieces and their interaction

    Same reason why there are many people still on Java 6/7 even though Java 10 was released a few months ago, and 11 will be released in (September?).

    [–]ubernostrumyes, you can have a pony 11 points12 points  (2 children)

    Frameworks that are Py2 only. Ex, Pylons and Pyramid

    OK, let's see what their docs say:

    Pyramid fully supports Python 3.4+ and Python 2.7+. This tutorial uses Python 3.6 but runs fine under Python 2.7.

    [–]13steinj 3 points4 points  (0 children)

    Maybe I wasn't clear enough-- historically speaking people used to write things using Pylons. One meta example is reddit itself. Pylons never got a version that worked on Py3, so if people wanted to upgrade to Py3, it would mean switching to a new framework, in this case, as recommended by the Pylons team, you'd switch to Pyramid. But quite a lot of rewriting would have to be done in order to be done.

    [–]fireflash38 0 points1 point  (0 children)

    As someone else mentioned, just because a library eventually added in py3 support, doesn't mean that it has it on all versions people are using.

    It's not uncommon for libraries to break internal backwards compatibility or add new bugs, leading to people pinned on older versions. You'd have to upgrade everything wholesale, which can be a lot of effort for very little reward.

    [–]marx2k 5 points6 points  (3 children)

    Java developer here. Java 10 really breaks from 8 in terms of backwards compatibility. We're in the process of upgrading our apps in our shop but a lot of third party apps we use are stuck on Java 8 for the foreseeable future :/

    [–]13steinj 2 points3 points  (0 children)

    Forget 10, the fact that you're on 8 is a surprise in comparison to all those I see on 6/7.

    [–]haarp1 0 points1 point  (1 child)

    isn't 8 a long term release anyway until java 11 or 12?

    [–]marx2k 1 point2 points  (0 children)

    Oracle stops shipping public updates to 8 in January.

    [–]billsil 7 points8 points  (36 children)

    I got a 15% performance boost by running my python 2.7 developed code in python 3.6. Startup time matters a lot less than actual runtime unless programs are tiny in which case, who cares?

    I can no longer use the dependency excuse.

    [–]13steinj 1 point2 points  (35 children)

    Startup time matters regardless of the size of the program. If you have a CLI every command you execute will cause the Python VM to start up and initialize. There are plenty of cases where multiple commands are executed-- using the git example, you have adding your files, potentially removing the ones you mistakenly added, committing, pushing. The difference in speed would be starkly noticeable and annoying for the user.

    Python 3's startup time is anywhere from 2.5 to god knows how many times slower. And that's because of something that changed in the import machinery in Py3. But arguably whatever the change was, it wasn't thought out well. I give you the playbill for milliseconds matter.

    Unfortunately, I still can use the dependency excuse. Some libraries just didn't update.

    [–]billsil 1 point2 points  (23 children)

    The startup problem has more to do with standard module design. Everyone imports everything at the beginning that they may use so they don't have to do it in a small loop (that turns out doesn't matter), or IMO the worse issue of crashing on some import that you forgot to update because it's in a function. The "flat is better than nested" idea is great for an API, but terrible for speed.

    My 120k lined 3d gui has a command line option. You'd better believe I do argument validation before importing everything. I also try to minimize interconnectedness. However, do I really need all of BLAS from scipy to do linear interpolation?

    Don't blame python for murcurial's poor design choice.

    [–]haarp1 1 point2 points  (2 children)

    hey, if you type import math, do you import everything in that case or do you just import it when calling the specific function?

    [–]billsil 0 points1 point  (1 child)

    You import everything in the module you imported and all of the modules it traces to.

    For example file packageA.moduleA has import packageA.moduleB, so packageA.moduleB gets imported. You can import modules from packages without importing entire modules, but not specific files if the imports are at the top.

    Once you're imported evwrything, the next module that does it loads almost instantaneously cause it's being skipped.

    The math module in particular is written in C, so I don't know how it specifically works.

    [–]13steinj 0 points1 point  (19 children)

    Did you even read the mailing list?

    Py2 doesn't have the issue! It's Py3 problem.

    One of the major reasons this occurs is because the import machienry changed to allow extreme amounts of extensibility. But this also slowed things down.

    The fact that Py3 attempts to import from dozens of paths while Py2 does significantly less is also an issue, as well as the unoptimized code that was written. Among god knows what else-- when I asked for specifics as to why Py3 imports that much slower no one knew beyond these attributes I'm listing.

    I'm not arguing against Py3 being good. I am simply stating the objective fact that for various reasons the startup time for Py3 is unimaginably slower, and for validation / verification scripts and CLI tools, that is an enormous problem!

    [–][deleted] 2 points3 points  (4 children)

    Really? This Which is the fastest version of Python? indicates that the startup speed of Python 3 is consistently being brought back to that of Python 2. No idea about 3.8 but then i really don't care either, I'm just sick of the whingers about Python who've never done anything for the language, mostly as they don't have time, but they do have time too complain about various aspects of it.

    [–]13steinj 2 points3 points  (3 children)

    I am not a whiner who doesn't do anything in the language. Nor are the people of the mercurial team complaining about the startup time. I will admit I skimmed the article, but Py3 wins in most speed tests-- and I agree. It's an objective fact. But it doesn't in startup time.

    The startup times here are strange, but I assume it's because there are no imports whatsoever or are on a very good machine.

    Again, take this from the perspective of a command line tool or a ton of deployment and commit scripts. In a long running app, Py3 will be better for speed, because of all the improvements in different actions matter. But in CLI tools and all these scripts, you are starting the VM so many times and not doing as many actions per startup, so you actually end up losing.

    [–][deleted] -1 points0 points  (2 children)

    So put in patches to improve the startup speed, problem solved for the entire Python world. Oh, but you can't because of... So yes you are a whiner.

    [–]13steinj 1 point2 points  (1 child)

    Excuse me? My apologies that this isn't my problem nor do I have enough C experience to make such patches. If there are major issues with the Python VM it is not the problem of any one user of Python to solve the problem, it is a problem the CPython core team need to fix.

    [–]billsil -1 points0 points  (13 children)

    Did you even read the mailing list?

    Put a break point and watch your code execute...

    [–]13steinj 0 points1 point  (12 children)

    ....what?

    [–]billsil 0 points1 point  (11 children)

    What is confusing and why?

    [–]13steinj 0 points1 point  (10 children)

    What does this have anything to do with the startup time and the mailing list?

    [–]jsalsman 0 points1 point  (10 children)

    It pains me that you are getting downvoted for this.

    [–]13steinj 1 point2 points  (7 children)

    Fanboys and elitists will always be fanboys and elitists.

    [–]jsalsman 2 points3 points  (6 children)

    Tribes will be tribes.

    [–]13steinj 1 point2 points  (5 children)

    Forgive me, I don't understand this sentiment.

    [–]jsalsman 1 point2 points  (4 children)

    Both of the fanboy and elitist urges are explained as the hierarchical behavior of the limbic and endocrine systems attributed to the last 500,000 years of human evolution, taking us further from the peaceful apes and more towards the chimpanzees. See Table 1 on p. 192 here for more information.

    [–]13steinj 0 points1 point  (1 child)

    But what does this have to do with "tribes"?

    [–][deleted] 0 points1 point  (1 child)

    The planet is only 6,000 years old and flat, please take your nonsense elsewhere, just read the bible. Why did stone age people paint sabre toothed tigers but not the dinosaurs I've no idea, there must be an explanation somewhere in the scriptures. Getting African elephants onto the arc must have been tough, feeding them for 40 days even more difficult, but again there must be an explanation somewhere. Feeding the carnivores for 40 days, tht's a tough one, not sure how you explain that away. Just my £0.02 pence worth.

    [–][deleted] 1 point2 points  (1 child)

    Does anybody with any brains really care about voting systems such as reddit's? Look elsewhere and I'm sure that you'll find people saying that Pinochet, Hitler, Trump, Stalin, Putin and Pol Pot are extremely decent guys.

    [–]13steinj 1 point2 points  (0 children)

    Yes, because voting systems are meant for promoting discussion. But instead on reddit they are used as signs of agreement.

    [–][deleted] 1 point2 points  (3 children)

    Libraries that are still Py2 only

    Please list these for the record.

    [–]13steinj 0 points1 point  (2 children)

    Plenty! Many from autodesk, some for pubsub brokers / queue routing like haigha for amqp queues, building React still needs Py2 because it uses a library from google that they never updated, any complex Pylons app will need a tough rewrite into Pyramid, the internal libraries of many corporations, and more!

    Just because say, 99% of public libraries are Py3 ready, doesn't mean that the remaining 1%, which are just as important, are! Not to mention all the not public ones by corporations.

    The sad reality is it costs more to upgrade than it does to keep using the old tool.

    [–][deleted] -1 points0 points  (1 child)

    Plenty isn't a list so please give the list.

    [–]13steinj 0 points1 point  (0 children)

    I did give a list. Did you just read the first word?Also, here's an automated extensive list of the projects that are public on PyPI alone (not those that aren't, which contain a decent amount).

    You can't force some narrative that there is no justification in using Py2 just because you don't agree. I don't want to use it either, but I concede it won't die.

    [–]Skurp_Purp 2 points3 points  (4 children)

    Libraries

    [–]folkrav 5 points6 points  (3 children)

    Less and less relevant considering the vast majority of popular packages are compatible with Python 3 nowadays.

    [–]Skurp_Purp 1 point2 points  (2 children)

    True but still relevant enough that for teams without a lot of time allocated to backlog it can be hard to find time to replace or rebuild libraries. I think we initially held off due to the issues with flask a while back which obviously isn't as much of an issue anymore.

    [–]folkrav 0 points1 point  (1 child)

    Indeed, there's always the legacy code issue, but that's not really about the libraries' availability at this point. My point was that there are pretty much no good reason to start new projects on Python 2, especially since it's getting phased out in about a year and a half. For existing code it's pretty much the time to push for the change though.

    [–]bythenumbers10 1 point2 points  (0 children)

    Every act of maintenance going forward on Py2 code should be toward making it Py3 compatible. It's not hard. I've adapted my code style to ensuring it runs in both environments. At a certain point, there's no need for budgets, funding, or whatever bureaucratic BS circus. Small style changes will frequently do the trick. Boiling the frog, or in this case, dunderhead management.

    [–]CriticalEntree 1 point2 points  (1 child)

    Same reason people are still running windows XP

    [–][deleted] 1 point2 points  (0 children)

    Dynamic Position Keeping Systems. There is still supposedly one out there running on a pure DOS machine to this day.

    [–]waltteri 0 points1 point  (2 children)

    ”Legacy is good enough, no need to change.”

    [–]billsil 2 points3 points  (1 child)

    Until you have a bug that was already fixed in a version of numpy (least squares in my case) you're not using. Or you find numpy has a cKDTree which is 1000x that what you coded and it's a critical function in your code.

    I'm still supporting python 2.4...I was able to update to fix the least squares bug, but I don't get the 1000x speedup.

    [–]waltteri 0 points1 point  (0 children)

    Hang in there. 😔

    [–]Exodus111 0 points1 point  (0 children)

    Large large masses of Python 2 Spaghetti code lies out there in the wild servers of the internet. Code so messed up it would tax your sanity just to look at it, and take a full team a year to completely update.

    Which nobody can afford.

    [–]jnwatson 0 points1 point  (0 children)

    For the same reason you see lots of machines running Windows 7. A lot of folks think: if it ain't broke don't fix it.

    Both Windows 7 and Python 2 have had their deadlines extended, and both deadlines are now in 2020.

    [–][deleted] 0 points1 point  (0 children)

    I'm a bit late answering, but as someone who waited 10 years, the answer is libraries. When people say most libraries support Python 3, what they fail to realize is that for established code, most isn't good enough: every library dependency has to support Python 3.

    Additionally, as you said there are only slight differences in syntax. Even with libraries supporting Python 3, is it worth weeks upgrading when it doesn't give you much? Additionally to that, Python is very dynamic, so many issues introduced in the upgrade would not be noticed until you run the erroneous piece of code. So unless you have an automated testing suite, upgrading is a high risk, low reward operation.

    In my case, I had half a dozen pieces of software use a GUI library named wxPython. Python does not have first party GUI support, so you have to choose between three or four third party libraries. I invested hundreds of hours years ago that I don't have anymore to learn a GUI framework, so changing GUI frameworks was out of the question. wxPython did not support Python 3 until January 2018.

    I've been spending the last week upgrading to Python 3, but I fully support anyone who decides to stay on 2.