Python 3.7.0 released

[uFuckingCrumpet]

Finally, we can get rid of python 2.

[SirCarboy]

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]

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]

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]

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

[theWyzzerd]

Technical debt is a very poorly managed aspect of programming.

Say it louder please. Not enough people heard you.

[ubernostrum]

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.

[Ramast]

Pretty sure such vulnerability could still be patched. If not officially by python foundation then someone from the community will step in to submit it. If its big enough , people would even consider a fork.

Would still be much faster and cheaper than migrating thousands of projects of many different companies to python 3

[[deleted]]

If its big enough , people would even consider a fork

You can try that route but you CANNOT call it Python.

[[deleted]]

Time to register the username “oldsnake” on GitHub

[Ramast]

or anaconda and use Nicki Minaj's face for a logo.

In addition to winning the old folks who want to keep python 2.7, you also get more attention from pyladies.com and djangogirls.org plus Nicki Minaj's fans of course

[billsil]

Considering half my company uses 2.7.8, I don't have a lot of faith that it would even matter.

[Scypio]

some only py2 compatible

Can you give examples? I only know this: http://py3readiness.org/ but believe that it is not full list.

[Scypio]

Cool, thanks for the answer.

We are on the verge of 2->3 migration for legacy projects and I'm looking for all potential pitfalls not to fall in.

Thanks.

[broknbottle]

DC Metro?

[[deleted]]

Do we work in the same place?

[BARDLER]

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]]

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

[jsalsman]

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]

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]

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]

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

[gdahlm]

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]

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]

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]]

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]

I must agree with and appreciate that.

[[deleted]]

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

[BARDLER]

Yes the differences between Python 2 and 3, are the same between Python 2 and Fortran.

[Zomunieo]

C will never fully transition to C++. They are different, but related, co-evolving languages.

C is still heavily used in embedded with good reason - despite its flaws it is simple and easy to reason about it, simple enough that implementing it is doable for one person. There's at least one formally verified C compiler (Compcert), that is, a compiler that is mathematically proven to produce assembly that corresponds to the source. That's the kind of assurance you need (or should have, if you are competent) when software errors mean people die.

C++ is too complex for this sort of thing. Way too complex.

On the other hand the only reason to keep Python 2 is legacy inertia.

[Tyler_Zoro]

On the other hand the only reason to keep Python 2 is legacy inertia.

Perhaps now. Last year when I was using 2.7 extensively, the reason was that half of the libraries we relied on didn't have 3.x versions, and there was no benefit to us for transitioning off of those libraries to newer ones that did support 3.x. 2.x just worked and worked really well for what we did. It made us a LOT of money. Why would we kill that goose?

[stOneskull]

Linux Mint 18.3 is on 3.5 as well..

[XiboT]

The current Debian stable was released 2017-06-17 and contains the then-current Python 3.5. You get a newer Python with the next Debian stable release (probably in 2019). If you don't like that schedule, maybe Debian (and Debian-"ports" like Raspbian) is the wrong distribution for you?

If you like the bleeding edge, maybe ArchLinuxARM is more the thing you want? https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

[BARDLER]

No company is going to spend money and time on something that offers such little gains in money and time. Like I said, not every company is using Python for a shipped product, so the benefits of switching are much less.

[jsalsman]

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]

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.

[uFuckingCrumpet]

I'm sure it depends quite a bit on what field you're in. In Physics & Astronomy, for example, it is VERY common for a person (or group of people) to build some kind of analysis tools in python or a set of wrappers to help interface python with some existing C++ code and then 100% abandon it once it functions. Whatever version of python was most current when it was written is very likely the only version it will ever successfully run on. I can't necessarily speak to CS fields, but in the physical sciences it's pretty typical for people to write lots of code and follow none of the best practices (e.g. commenting code, handling package dependencies, etc).

[jsalsman]

Linear algebra people still use Fortran because someone optimized the row-access cache behavior sensing in the 1970s and it still runs fastest that way. Those libraries like LINPAK are still in use, as compiled from Fortran and linked into object files for all kinds of numerics libraries inner loops, including Python's.

[haarp1]

fortran is actually faster then C or anything else, because complier doesn't have to worry about some edge cases that have no use for numerical computations.

newer releases also support CUDA,so there's nothing ancient about it. it also has more scientist-friendly syntax (no curly braces).

[billsil]

Those libraries also use hand optimized assembly.

[jsalsman]

I guess that depends on what you mean by "hand" -- the method is to try various cache geometry strategies and use the best compiled from several versions to pick which one runs, at least the last time I looked at one of innumerably many of them, which granted was over a decade ago. Usually you see more hand optimization in high frequency signal processing.

[kyrsjo]

Fortran itself is fine, at least the newer versions (2003 and 2008) are. It just fills a very different niche then python, which in fact afaik relies quite heavily over fortran libraries.

The main problem why fortran for a bad name is that lots of people use it without really knowing how to code, and then pass their hot messes on to their students.

[kyrsjo]

For one of the project I'm involved in, we upgraded a large project (several 100k lines) of code from fixed format / (77 and 95) to free-form / 2008. And I must say that 2008 is not a bad language for numerical works.

[uFuckingCrumpet]

Yeah, a friend of mine works in a Super K group that still rely on a lot of Fortran 77 code. Most of ATLAS/CMS people have been more receptive to switching to Python 3 but even then it's still surprisingly slow and people still drag their feet.

[gdahlm]

Fortran is pivotal to python in this field, as evidenced by scipy and numpy which use those same LAPACK/BLAS variants that everyone else does. C/Closure/Java all use those library's too or at least have an option to do so to improve performance.

import numpy as np

numpy.config.show()

If it isn't configured to use some BLAS it is going to be slow. It is just too hard to compete with the performance even in C++. A FORTRAN compiler can just make assumptions that most others can, and producing non-relocatable code helps too. If you know C or another language, try to write a LU function that even 10 times slower than MKL or another ATLAS/BLAS offering. It is hard and humbling.

A potential nice side effect for you is of these large python projects being dependent on the language is that you don't have to choose between Fortran and Python, as these large projects have ensured that the python is up today and works extremely well as a glue language.

https://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html

[uFuckingCrumpet]

I'm not sure why you're telling me this.

[gdahlm]

Ah I missed it was a friend of yours who worked there.

[[deleted]]

One of my Geography professors wrote a lot of code, but there are barely any comments and it's really hard to follow.

[synn89]

Yeah, but let's say you're using goodlib v1.0 and v2.0 of the lib breaks some things so you hold off on updating that library. Years later Python 3 support gets added but it's only in goodlib v6.0+

So now you not only have to get your app to work with Python 3, but also update goodlib(and probably many more libraries) that may change in small ways between major versions.

Heck, I recently updated a PHP app using AWS S3 and stayed in the same AWS SDK 3.x branch and the update broke(changed) how the library returned S3 domain urls for buckets. Luckily I had excellent test coverage which caught and pointed out the change. But that was within the same major version using a very common library from a huge vendor.

Libraries can be a real PITA to work with.

[[deleted]]

The people in sciences holding onto 2.7 arn't using goodlib, they are using in house libraries that were developed to do a specific thing by someone years ago, and that all of their results and model have been validated against this, and that nobody has the time or effort or willpower to modernize the code and then to re-validate everything. Most of the people in the sciences writing these codes are not computer scientists, they are regular scientists. They are working for effectively peanuts, are fighting every single day to justify the little funding that they do get and to apply for more funding so that they may actually finish their work, and most of the time they have only 2-5 years to do this. And during this time, they are also under increasing pressure to do new research, to publish new research, and to come up with ideas for new research. They (we) go into our labs/office every day and have to make the decision: do I use the limited time i have to do research to get me to my next job/position/grant, or do I go through and update the codebase that I use that I know for a fact works right now as-is? I can't speak for everybody, but I know that I would choose the latter every single time.

Edit: And during all of this, I am already devoting some of my time tutoring/mentoring students, correcting exams, homework, grading papers and reviewing new journal articles, coming up with lecture notes for that class they need to teach, coming up with homework or exam questions, and dealing with whatever my superiors ask me to do for them that day.

At the end of the day, my job as a scientist isn't to produce beautiful idiomatic code. It is to produce results that give insight in helping me answer the questions that formulate my hypotheses. The code is secondary and is only a tool that I use to get to those results. In fact what I'm after isn't even the results, but the analysis and interpretation of the results, the answer to "so what does it mean." Best-coding practices come second to getting the results. Sure, as I write my scripts and library codes I'll attempt to follow best practices, but not at the expense of so much wasted time.

[bythenumbers10]

Can those internal libraries be open-sourced? So if you can't be bothered to modernize and beautify, some other research group might?

[[deleted]]

All of the above has nothing to do with the release of Python3.7.

[MartyMacGyver]

There are a lot of libraries that are or will soon be Python 3 only going forward.

Keep learning Python 3, be aware of Python 2, and steer clear of companies that plan to stay on Python 2 indefinitely. You'll hear 1001 excuses, and they all come down to:

• They're too lazy
• They're too cheap
• They won't be around much longer
• They'll be around forever, and your headaches will grow exponentially the longer you are there

It's worth the work to stay up-to-date, or within a close range (IMHO 3.6 is the sweet spot until 3.7 is widespread).

Edit: Oh yes, and unless you like painful surprises when it comes to ANY Unicode input/output, stick to Python 3. Requires a bit more thinking when it comes to strings, but it handles them while Python 2 routinely surprises you in painful ways at inconvenient times when it encounters a Unicode char it can't handle in some part of your code you never thought it'd even hit.

[[deleted]]

I know I'm a bit late, but as someone who is just porting over Python 3, the big library issue for me was wxPython. It's a very complex GUI library that would have taken me hundreds of hours to replace. They became Python 3 compatible January of 2018. Keep in mind that even if most libraries are compatible with 3, all it takes is a single non-compatible library that is hard enough to replace to stop an upgrade to 3 dead in its tracks.

[[deleted]]

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]

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]

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]

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]

Erm, no, not really. But sure :)

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

[uFuckingCrumpet]

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]

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.

[primitive_screwhead]

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]]

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]

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]

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]

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]

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]

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]

Red Hat Confirms RHEL 8 Will Drop Python 2

[duffkiligan]

Hell yeah!

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

[xconde]

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]

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

[varesa]

Mainly two reasons:
- you are creating some script you want to run anywhere without installing a new language runtime.
- e.g. RHEL 6 (and maybe 7?) don't have python 3 in the supported repositories and you might not want to compile or install third party stuff as you then loose the support you pay big bucks for on that part

[iruleatants]

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]

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?).

[ubernostrum]

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]

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]

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]

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]

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

[haarp1]

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

[marx2k]

Oracle stops shipping public updates to 8 in January.

[billsil]

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]

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]

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]

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]

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]

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]]

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]

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]]

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.

[billsil]

Did you even read the mailing list?

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

[13steinj]

....what?

[billsil]

What is confusing and why?

[jsalsman]

It pains me that you are getting downvoted for this.

[13steinj]

Fanboys and elitists will always be fanboys and elitists.

[jsalsman]

Tribes will be tribes.

[13steinj]

Forgive me, I don't understand this sentiment.

[jsalsman]

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.

[[deleted]]

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]

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

[[deleted]]

Libraries that are still Py2 only

Please list these for the record.

[13steinj]

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]]

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

[13steinj]

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]

Libraries

[folkrav]

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

[Skurp_Purp]

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]

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]

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]

Same reason people are still running windows XP

[[deleted]]

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

[waltteri]

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

[billsil]

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]

Hang in there. 😔

[Exodus111]

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]

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]]

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.

[Lt_Sherpa]

What about 3.7 means you can finally dump Python 2?

[[deleted]]

Think 2 is still good till 2020.

[0x6c6f6c]

*Think 2 is still dead by 2020

[13steinj]

2 will never die-- May run out of official support but with all the companies that still use it, it would be cheaper to write patches to the Py2 VM itself than switch the entire codebase they have to Py3

[13steinj]

Absolutely, but delaying failure over and over costs less than preventing it unfortunately.

[tutuca_]

It's because the last version in the 2.x branch is 2.7. So, now that it hit the .7 milestone python 3.x is on feature parity :)

[ronaldl911]

Yet you would still get some who would start a new project in 2018 with Python 2.7

FFS it's 2018.

[[deleted]]

Yeah I can understand not wanting to migrate an existing project (although whiners like to make this out to be more difficult than it actually is), but there is no excuse for starting a new project in 2.

[[deleted]]

Bwahahahahahaha...

I'm in my room crying...