
Sunsetting Python 2 - azizsaya
https://www.python.org/doc/sunset-python-2/
======
ken
Python 2 to 3 (at least by 3.3 or so) was one of the _easiest_ transitions
I've ever done. There's a library ("six") to help, and in almost all cases you
can write 2-and-3 compatible code, which means you can go piece-by-piece.
(Unless your manager makes drive-by commits of py2-only code, months after you
all agreed that all new code should be py3-compatible, and then leaves town
for a multi-week vacation...)

Dependencies? I helped upgrade a couple third-party modules, too. That's part
of the job. If you choose to use a dependency, you're vouching for it. That
means if the current version of the language no longer supports your favorite
library, you need to fix the library, or find a new one. If we switched from
phillips to torx, and your favorite tool brand didn't make torx drivers yet,
you've got to either convince them to start, or switch brands. Professionals
don't get to use this as an excuse to badmouth torx, and stick with phillips.

If people spent half as much energy upgrading as complaining, this would have
gotten done 5 years ago.

Apple took only 3 years to go from first announcing a new CPU architecture to
releasing an x86-only OS. 2 years later, Rosetta stopped working, so there was
no way to run old apps on current hardware at all. That's got to be one of the
advantages of proprietary systems. It's amazing what you can accomplish when
you have no choice. People complained a little but they got it done.

~~~
ofibrvev
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions
> I've ever done.

Good for you. Some of us had code bases of considerable size and complexity
though.

The fact is that for working software on the python platform, this upgrade
represented work that had to be done that for a legacy app that was still
chugging... little benefit. If you already coded around the python 2
limitations for Unicode eg, then python 3 was not a help at that point for
something already in service. It was just more cost for no benefit.

> If people spent half as much energy upgrading as complaining, this would
> have gotten done 5 years ago.

These aren’t exchangeable. Why do people on the internet think bitching
(either constructive or not) is some valuable currency? Often times the people
complaining had no means or position to of the work. 4 promotions later I sure
as hell wasn’t going to participate in that 2 to 3 mess on a project produced
years ago, but I could still opine in the situation. I also had little
incentive to fund it.

Your analogies are bizarre. No idea what you’re trying to convey with philips
v torx but I’m going to wager it’s explanatory power in this case is shit
anyway. I can still demolish it, having actually worked in manufacturing there
were times _we_ told a supplier (ie Python) to fuck off and piss up a rope
because what they were proposing was not compatible with our existing tooling
and it would be too costly to convert for little benefit to us.

I respect apples prowess in the consumer space, but there’s a reason you don’t
see their products regularly put into industrial roles where your timeline is
more than 5 years. Apple products are disposable, many applications in
industry are expected to last. Python is a general purpose programming
language (or at least billed itself as such). Your comparison is poor.

~~~
djsumdog
You have a dependency rot problem. Are you missing unit tests? Because having
a ton of unit tests can reduce dependency rot, breakage and overall make
engineering upgrades just a lot easier to deal with. They don't catch
everything of course, but they can catch a lot.

If you haven't put in the priority to update your Py2 to Py3 apps by now, I
really think your shop has the wrong priorities.

It's not just about Py2/3\. Dependency rot is one of the worst form of
technical debt. It often shows broken CI, broken security scanning, lots of
generally broken processes that will just keep hurting a team further and
further down the line.

~~~
cortesoft
> If you haven't put in the priority to update your Py2 to Py3 apps by now, I
> really think your shop has the wrong priorities.

I am not sure how you could possibly know this. You have no idea what else
they were working on instead.

~~~
ptx
Because no matter what you're working on, you won't get very far without
eating, sleeping and at least once a decade putting in some maintenance work.

------
drej
What surprises me about this is that the documentation for Python 2 does not
explicitly say that the language version is about to be unsupported, see e.g.
[https://docs.python.org/2/library/zipfile.html](https://docs.python.org/2/library/zipfile.html)

Contrast this with the Postgres website, which tells me I'm browsing old docs
(because Google still offers old links), see e.g.
[https://www.postgresql.org/docs/9.2/tutorial-
window.html](https://www.postgresql.org/docs/9.2/tutorial-window.html)

Are there plans to add a banner to Python 2's docs? I think it would be quite
instructive.

~~~
pelario
I cannot agree enough.

As a casual python user, it is quite common to stumble in some issue, after
somme googling land in a doc page, try my solution, and find it does not work.
Then googling after the failed solution, noticing that the previous doc page
was describing a Python 2 feature that do not exists (or works different) in
Python 3.

~~~
lonelappde
This issue is part of why Haskell is so hard to learn. Haskell's package
database Hackage keeps all old deprecated incompatible versions of packages,
with documentation pages all well indexed by Google, with higher page rank
because they are longer lived than the current package version, with no
indication that they are deprecated and incompatible with current Haskell
deployments.

~~~
madsbuch
This is also the problem haskell stack solves

~~~
__jal
"Haskell. The cause of, and solution to, all of life's problems."

~~~
taejo
"Stack" is the name of a product; it wasn't a generic reference to "the
Haskell stack".

------
jedberg
In 2015, there was no way I could have moved to Python 3. There were too many
libraries I depended on that hadn't ported yet.

In 2019, I feel pretty confident about using Python 3, having used it
exclusively for about 18 months now.

For my personal use case at least, this timeline worked out well for me.
Hopefully it works out for most everyone. I can't imagine they made this
decision without at least some data backing it up.

~~~
reitzensteinm
Based on your timeline, a four year gap from "not yet ready to migrate" to "we
won't fix security vulnerabilities" is very short.

Python is an open source project I've used and contributed nothing to, so I
don't have the right to be a back seat driver. Were it a commercial project
and I was a customer, I would be quite upset.

~~~
shakna
Python 2's EOL was first announced in 2008, it was extended in 2014. That's
more than a decade of forewarning that this was coming down the line. A decade
of Python2 receiving security fixes.

Were I a commercial customer, and had been told to switch to the new version
ten years ago, then it's on me if I still have started the migration yet.

~~~
mantap
You couldn't switch to Python 3 until the middle part of this decade unless
the stars aligned with your dependencies, the library support wasn't there.
And the first releases of Python 3 were glorified betas, the first "usable"
version of Python 3 is often considered to be version 3.3 released in 2012.

~~~
ensignavenger
But you could easily write Python 3 compatible code so that upgrading once
your dependacies were ready was easy. You also could have contributed to your
dependancies to help them become Python 3 compatible.

~~~
mikepurvis
Quick: run a shell command, split up the reply by line, run a regex on each
line, and save the results to a yaml file— now, does what you wrote work
correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought.

It's still hard to get bilingual Python correct today, and it was considerably
harder before 3.3.

~~~
radus
Okay, I did it.

    
    
        import subprocess
        import re
        import yaml
    
        output = subprocess.check_output(['ls', '-l'], universal_newlines=True)
        matching_lines = []
    
        for line in output.splitlines():
            if re.search(r'total', line):
                matching_lines.append(line)
    
        with open('matching_lines.yaml', 'w') as f:
            f.write(yaml.dump(matching_lines))
    

Python 3.7:
[https://repl.it/repls/PotableDamagedAutocad](https://repl.it/repls/PotableDamagedAutocad)

Python 2.7:
[https://repl.it/repls/OrchidDirtyNotification](https://repl.it/repls/OrchidDirtyNotification)

~~~
mikepurvis
Nice. Yeah my life got a lot easier when I learned about `universal_newlines`
changing the subprocess return type under Python 3.

The much worse case of this that I dealt with a few years ago was reading in
and modifying XML files, and then saving the modified XML contents as strings
in a yaml file (a keyed cache). The input XML files (which I didn't control)
were not consistent about having the encoding marked, and that really made
things a mess for ElementTree.

A taste: [https://github.com/ros-
infrastructure/rosdistro/search?q=utf...](https://github.com/ros-
infrastructure/rosdistro/search?q=utf-8&unscoped_q=utf-8)

------
coldtea
> _If people find catastrophic security problems in Python 2, or in software
> written in Python 2, then volunteers will not help you. If you need help
> with Python 2 software, then volunteers will not help you._

Well, isn't it the benefit of FOSS, that volunteers can, and in the case of
such a critical piece, so much used as Python 2, in all probability will, step
up. Doesn't have to be the same people as the core team if just security fixes
are involved...

Not to mention paid FOSS developers at places like RedHat, who want to keep
supporting their LTS and enterprise customers...

~~~
mrweasel
I honestly don't believe that many will step up and take over. Many will
complain, but few will do the actual work.

Even if it's just security fixes, there's still the process of testing and
release management, and honestly, I don't blame the core Python team for no
longer wanting to do release management of both Python 2 and 3.

~~~
CJefferson
The biggest problem is having a place to organise.

The Python foundation is threatening to sue anyone continuing something called
Python 2, or even a similar name.

Finding volunteers who are willing to get sued to work on Python will be hard.

~~~
wongarsu
Continuing a fork under the original name would be confusing to everyone and
bad manners, aside from infringing the trademark. But nobody is stopping
people from organising around a fork called "Omphalos - a Python 2 fork" or
whatever

~~~
toyg
Somebody has done just that already, it’s easily googleable. Nobody really
cares though - why would you purposefully tie yourself to an objectively-
inferior featureset, full of problems that have already been solved in py3?
Because you can’t bear the use of parentheses for print, really?

~~~
jsjohnst
> Because you can’t bear the use of parentheses for print, really?

While I generally share your POV, it doesn’t do justice to the situation to
trivialize the upgrade like that. Anyone with C based dependencies will have a
rougher time (but not that “rough”) due to ABI changes. The harder userland
change is string handling anyway (which isn’t that hard either), not parens on
print.

~~~
toyg
You are right. I'm probably still shellshocked by the initial wave of
complaints, so many years ago...

------
carapace
Going forward, I'll be maintaining Python 2.7 for the indefinite future. This
will be under project name "Bladders". (Python is named after Monty Python's
Flying Circus. There is another fantastic British comedy called Black Adder,
and the main character is sometimes called "Bladders" as a contraction of
Black Adder.) Unlike Tauthon, I won't change the language at all, only
maintenance. I'm also going to make a curated software repository of Python 2
code, starting with the standard lib and some common third-party packages
(like Snakefood.) And I'm going to _pay_ technical writers to clean up the
documentation.

I don't give a fig about controversy. I just want to keep using Python 2.

~~~
kstrauser
But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly
better than 2. With the upcoming 3.8, it seems to be better in every way
(including performance!).

I loved Python 2 for a long time. It was a beautiful language. But after
seriously using 3, I would never go back. As in, I would turn down job offers
involving Python 2 in any other context than "we're hiring you to help us
upgrade".

~~~
carapace
> By 3.6, it was markedly better than 2.

Better how? Or better at what?

It's likely that our opinions will be different but I've got an open mind and
I'm genuinely curious about your experiences and opinion.

(I hated PEP 572 at first but then some comment here on HN made me rethink and
change my mind.)

~~~
kstrauser
f-strings. Enum. Dataclasses. asyncio. Type annotations as code. An explicit
separation between bytes and strings. I love each of these and use them
regularly. It's not that 2.7 is some abomination I can't stomach, but more
that 3.[recent] is all of the things I appreciated about 2.7, plus a million
little quality of life and performance enhancements that make it just that
much more pleasant to use. I could live without each of those things
individually, but would not be willing to give them _all_ up.

~~~
carapace
I can understand that (it sounds like me, talking about Python 2, eh?)

------
Animats
Some shared hosting providers are still offering Python 2.6 as their main
offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version.

[1] [https://www.hostgator.com/help/article/what-software-and-
pro...](https://www.hostgator.com/help/article/what-software-and-program-
versions-does-hostgator-offer)

~~~
bigiain
I bet there is still some shitty hosting company somewhere offering Perl4 CGI
script hosting.

Doesn't mean we should do anything except laugh at their incompetence (or
perhaps be impressed by their ability to monetise other people's
incompetence...)

~~~
simcop2387
No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts
to run on my pastebin, [https://perl.bot/](https://perl.bot/) . In this case
it's not incompetence but insanity.

~~~
_kst_
How did you get the older Perls working? (I've tried and failed to get them to
build on Ubuntu.)

~~~
simcop2387
Manually patching the source in a few places, most of the time it's just
adding a header file or two since some of them predate ANSI C and the
standardized header files. The other things have to do with adding -DHAS_...
to force them to know that opendir and friends are actually present, so that
make install will actually work.

~~~
_kst_
Any chance you could release the patches?

------
EnderMB
While the article is very "matter-of-fact" about the sunset period and what it
means to those that still use Python 2, I'm still surprised that it's taken
this long to finally close support. I had assumed that their approach would be
to fork the language into a new language (call it something like Liasis) and
to allow one of the big-name contractors that specialise on Python 2 to take
ownership of it.

As an aside, a few weeks ago I interviewed at one of the top 5 investment
banks for a software engineering role to maintain one of their main trading
systems, written entirely in Python 2. My first question was what their plans
were in porting what they called "one of the worlds largest Python 2 code
bases," and it was "on the roadmap".

Surely the Python core team are aware that teams like this exist in some of
the largest companies in the world, and I assume they've had at least some
level of dialogue with companies like this to say "we're super serious this
time, we're about to stop support for Python 2", or something along those
lines?

Maybe it's a blessing in disguise that I was rejected?

~~~
sametmax
> I'm still surprised that it's taken this long to finally close support

That's because the Python community is too nice.

When Ruby or node broke compat, they just said "move or die". People moved.

When Python broke compat, they gave 7 years. People screamed, cried,
complained, sweared it was impossible for them, that life was hard and the PSF
was unfair.

They got an extension of 5 more years.

People still complained !

Hell, famous authors resented python 3 for years, refusing publicly to update
their book.

On the other hand, the PSF had a very small budget, only few tiny donations
and contributions by people or big companies that were saying they couldn't
migrate that their lines of code. The same code that were making them a
living, from a 25 years old amazing tech given to them for free.

My take on this is that if you are doing an open source project with a lot of
volunteer work, don't be too nice. People have a tendency to abuse it. Save
yourself trouble, and balance respect with users and convenience for you.

~~~
hoseja
Maybe also don't make tools targeted at people who can't use proper tools.

------
tibbon
One thing that confuses me about Python is just how many projects don't
specify if the app is supposed to use 2 or 3, and the correct answer isn't
'either'. Check out something from Github, only to find I actually do need
Python 2.7 or something. Is it that Python developers assume everyone will
just intuit the version, or is there a default?

~~~
toyg
Rule of thumb is that no version == python2, either because it pre-dates 3 or
because the developer's concept of python is "what happens when I type python
at the shell" so it's still 2. It's often a big red flag about quality;
competent Python developers find it natural to state py3 support upfront (or
lack thereof) because they know it matters.

~~~
BeetleB
Eh. Disagree. For small projects on Github that are actively maintained, it's
more likely to be Python 3 and not Python 2 if not explicitly stated. Newer
developers for newer projects just don't care about Python 2.

------
gigatexal
The transition to python 3 from 2 was rough I’ll give you that. But companies
and maintainers have had years and years to either fork and port or altogether
rewrite their code for python 3 — the only python that matters.

I liked the stance the post took: it was very matter-of-fact in its tone
regarding python 2 support — consultants are there for that and they will
charge a mint to give you time you should have taken to move your codebase to
python 3.

~~~
mk89
From my experience, large codebase refactorings are almost never a priority
until the deadline is just right there. 10 years for many companies mean the
last 6 months, when everyone else has already done a lot of work on the same
problems as you will encounter, lots of issues have been already solved, and
you can probably find people with the python 3 skill. And last but not least,
you will find approvals from management side "this year's the end of support,
it must be done, otherwise we are out of security patches". So, essentially
yes, they gave a lot of time for enterprise companies to let others do the
dirty work :)

~~~
ilikehurdles
That's true. I worked at an enterprisey shop that delayed upgrading from Java
6 before its EOL. By the time they started, the EOL date had passed a few
months prior and the upgrade itself was a 1.5 year effort. Some orgs can be
pushed, others have to be shoved.

------
voldacar
I long for the day when typing "python" into a shell will bring up a python 3
prompt

~~~
avian
Switch to Arch Linux and live the dream. It has had python3 as /usr/bin/python
since 2010.

[https://www.archlinux.org/news/python-is-now-
python-3/](https://www.archlinux.org/news/python-is-now-python-3/)

~~~
shpx
Also Gentoo since mid-2018.

Although their package management requires manually specifying the minimum
accepted Python version for every single package, so they have thousands of
packages that would run just fine on Python 3.7 but no one has the time to
manually check and label them as such. So their default is still 3.6 and using
3.7 as your default version is not well supported.

I wish someone told me Gentoo is a non-starter before I wasted an afternoon
installing it.

While we're on the topic, it's pretty stupid how PEP 394, the one that says
"python should point to python2.7", gives its reasoning as "because all Linux
distros except Arch do it this way" and then all the distros say "python
should be python2 because the PEP says so" for the next 9 (maybe more) years.
How is anything ever supposed to change?

------
cm2187
So they are sun-setting it 12 years after having introduced its replacement.

I think there is a parallel with the .net Framework. .Net core is a similar
breaking change (not the syntax of the language but very much so in term of
core libraries and project types). I wouldn't be surprised if .Net full
followed a similar timeline.

~~~
hit8run
.Net 5 will be reuniting the brands (Though based on .net core). So the Core
brand will be discontinued. Read more about it here:
[https://devblogs.microsoft.com/dotnet/net-core-is-the-
future...](https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-
net/)

~~~
leadingthenet
They're changing the branding ... AGAIN?!

------
choppaface
"What will happen if I do not upgrade by January 1st, 2020?" "You will lose
chances to use good tools because they will only run on Python 3, you will
slow down people who depend on you and work with you."

The tone in this document is excessive and over-the-top. If the author spent
half the document demonstrating (with examples) why Python3 is so great, it
might actually be useful and get people upgrading like right now as they're
reading it. But instead, it seems the author simply wanted to convey how sick
they are of Python 2. The author does not appear to understand their users;
that's their _real_ frustration.

In life outside of Python... The transition in C/C++ from C++98 to C++11 and
then C++20 (and beyond) has been quite clean and professional. There were some
glaring issues with C++11 that later got patched up (e.g. rvalues but no
optional, no filesystem, make_unique, etc). Most importantly, compiler support
and standard distributions improved a lot. There were often clear _incentives_
to upgrade, and it was relatively easy to stick to an old standard where
necessary.

In contrast, Python has become a bit fractured, with a number of notable well-
discussed but unaddressed loose ends in Python3:
[http://pyfound.blogspot.com/2019/05/amber-brown-batteries-
in...](http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-
but.html)

I think the Python community has failed to present strong enough incentives
for upgrading to Python3, and that's why users are sticking to Python2 and
'slowing everybody down'. The jump to C++11 was obviously needed: at the very
least, `auto` saved much of your sanity and you no longer really needed to
include Boost in your build. But you could stick to an old standard if you
wanted; you could even transition a codebase module-by-module in some cases.

The Python3 community seems to have been groping for a similar killer feature
(e.g asyncio, as discussed in Amber Brown's talk above), but the value-add
isn't so clear. `six` is honestly a nice catalogue showing how many changes in
Python3 are largely sentimental.

Perhaps the killer feature missing from Python3 is a flexible, built-in
Python2 runtime. Then maybe the transition would not have met such pushback.

~~~
jl6
Did we read the same document? It seems fine and a perfectly normal
explanation of what’s going on and why, like any software with a defined
lifecycle would have.

~~~
dagw
I guess it depends what lens you are reading it through. If you're used to
reading documents from open source projects it seems perfectly normal. If
you're used reading documents from Oracle and SAP explaining changes to their
long term support contract, then this will sound completely alien.

~~~
lixtra
If they had put “Pay x USD to continue using python 2 till 2020” in the
document, I bet it would have been less alien to oracle customers [1].

[1] [https://www.businessinsider.com/oracle-customer-explains-
aud...](https://www.businessinsider.com/oracle-customer-explains-audit-
threats-2015-9)

------
chirau
Honestly speaking this EOL was made clear almost 6 years ago. If you are still
on 2 you are probably best left to your own devices. 6 years is way way more
than enough time

~~~
intea
>in 2008, we announced that we would sunset Python 2 in 2015

More like 12 years by now :-)

------
jwr
When people mock me for writing long-term projects in Perl 5
([https://github.com/jwr/ccheck](https://github.com/jwr/ccheck)), I point them
to the Python2/3 change. From an outsider's point of view, this change was not
coordinated well and the timeline is too short.

To clarify: long-term means automotive time scales: I want to be able to run
my software in 10 years.

~~~
capitol_
If 12 years is too short, how long timescale do you need?

Python 2's EOL was first announced in 2008.

~~~
CJefferson
To be honest, never.

I work on a C program that's about 30 years old. We've slowly moved, at our
own pace, to C99, then added some C++ here and there.

I don't ever want to have a forceful change, where I have to go and edit code
which has worked correctly for over 15 years, just to make a compiler happy.

~~~
ilikehurdles
GCC deprecates and removes support for target architectures and various other
flags with each major release. If you care about receiving security updates
for your application, you have to upgrade the compiler, and to upgrade the
compiler you may have to make changes to your application and/or physical
hardware. Very few of the architectures that were available 30 years ago are
still supported by any maintained compiler today.

Similarly, developers are not forced to upgrade to python 3 any more than they
are forced to upgrade to GCC 4, in that they can keep using their old tools
but they're SOL on maintenance if they don't meet the requirements of the new
versions.

So, either your team chose really well 30 years ago, is actively working on an
horribly insecure application, or has invested some modicum of effort
periodically over the last 30 years to maintain support with the compiler
(unlike the developers complaining about Python 3's upgrade window).

~~~
CJefferson
We are moving CPUs, we aren't still using amigas and 386s :) but old C code,
broadly speaking, still compiles in gcc 8.

~~~
al2o3cr
Python 2 code, broadly speaking, still runs in Python 3. It's the not-broad
parts that are the problem...

------
ssully
On the topic of large companies still using Python 2, I would love to hear
about Splunk's upgrade plans. They have the following[1] on their SDK page
about upgrading, but my understanding is their entire platform is still on
Python 2.

I've upgraded a number of projects at my work to Python 3 this year, but
nothing that 2-3 developers couldn't do in a few weeks. Can only imagine the
headache of migrating something the size of Splunk.

[1]: [https://dev.splunk.com/view/SP-CAAAFG7](https://dev.splunk.com/view/SP-
CAAAFG7)

~~~
metasyn
Granted I don't work at Splunk anymore, but did recently. They were definitely
working hard on migrating everything to python3, and if I remember, they had a
planned roll out where python2/python3 would co-exist.

However, if you've been using the python SDK for Splunk - its been supporting
python3 for a few years already ([https://github.com/splunk/splunk-sdk-
python/commit/4503db961...](https://github.com/splunk/splunk-sdk-
python/commit/4503db9611d1475e9d49f69bd689540f5717e95f))

See this blog post: [https://www.splunk.com/blog/2019/07/01/admins-and-
developers...](https://www.splunk.com/blog/2019/07/01/admins-and-developers-
we-re-transitioning-to-python-3.html)

And this helpful doc:
[https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Mi...](https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Migration/AboutMigration)

~~~
ssully
Really appreciate those links!

I honestly had no idea the SDK has supported Python 3 for this long. Granted,
I haven't worked with it since 2015, but still surprised I missed that. Glad
to hear they are making such good progress.

------
sweettea
Sad to see them forging ahead on their plans to drop Python 2, and it would
have been nice of them to point out that other volunteers will provide
security fixes for Python 2 compatible runtimes.

I've switched to Tauthon [1] for over a year now and have been quite pleased.
Consider the switch yourself rather than rewriting your code.

[1]
[https://github.com/naftaliharris/tauthon](https://github.com/naftaliharris/tauthon)

~~~
jedimastert
In your opinion, is there any particular reason to start a new project, or is
this disappointment for lack of legacy support?

------
thefabsta
A popular library that has unfortunately not transitioned to Python 3 yet is
rospy (which is part of the larger ROS ecosystem for robotics). It is the last
framework that prevents me to fully embrace Python 3 for my everyday work. I
sincerely hope the robotics community will eventually port rospy (and other
ROS-related libraries) to Python 3.

I am, however, very happy to see that ROS2 (the next iteration of ROS) uses
Python 3 by default.

~~~
sickcodebruh
I'm in the same boat. It bothers me that my only option will be to rewrite in
Python 3. Unless they provide a very clear migration path, I'm far more likely
to just remove ROS entirely, unfortunately.

------
sireat
The otherwise amazing Windows service ninite.com is still offering Python
2.7.16 and is not offering Python 3.

There was a discussion on HN about this a few years ago, but I am curious to
see what does ninite.com plan to do now?

------
nickjj
I'm happy this finally happened, even though I've been clinging to Python 2.7
for quite some time.

I run a Flask course[0] and from the beginning I coded the app to work for
both 2.7.x and 3.x in parallel but it's only been a few months now where
Celery supported Python 3.7.

In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down
to making sure Celery is using 4.3+ and pytest requires 5+ if you plan to use
Python 3.5+. There wasn't any app level changes that had to be done other than
optionally removing some dual import try/excepts to work for both 2.x and 3.x.
The biggest pain point was remembering to use print with parenthesis but I've
been doing that for a while now so it's a non-issue.

This was based on a decently sized Flask app with tens of top level
dependencies and many thousands of lines of code.

If someone wants to see how this upgrade process looked in real time, I
recorded that and put it up on Youtube[1] the other week. The video also
covers some gotchas you might encounter during the upgrade process (especially
if you're running in production and deal with sessions).

[0]:
[https://buildasaasappwithflask.com/](https://buildasaasappwithflask.com/)

[1]: [https://nickjanetakis.com/blog/upgrading-a-dockerized-
flask-...](https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-app-
from-python-2-7-to-python-3-7)

~~~
guitarbill
pytest has has python 3.5+ support for a while, even 4.0.0 supported it:
[https://pypi.org/project/pytest/4.0.0/](https://pypi.org/project/pytest/4.0.0/)
. although the recent pytest changes are well worth picking up!

~~~
nickjj
> pytest has has python 3.5+ support for a while, even 4.0.0 supported it:
> [https://pypi.org/project/pytest/4.0.0/](https://pypi.org/project/pytest/4.0.0/)
> . although the recent pytest changes are well worth picking up!

Yes but check the changelog for pytest.

Version 5.x.x is only available for Python 3.5+. They dropped support for 2.7
and <= 3.4, unless you fall back to the 4.6 series.

------
adamhepner
Great stuff. But what about alternative python interpreters that have been
lagging behind? Jython is 2.7.1 and IronPython is 2.7.9

~~~
toyg
They are effectively both dead or moribund. Jython has had a py3 experimental
branch for ages but the entire project is basically starved of money and
effort.

To be honest, the whole “Python on other runtimes” movement, as a concept, is
more or less over. It’s just too much effort for too little reward, now that
CPython has good libraries for pretty much anything you can think of.

~~~
sjwright
Does that view include PyPy? I'm not deep into Python (aside from the _Monty_
kind) but it seems to be maintained and makes performance claims.

~~~
toyg
PyPy is a python-focused project that builds a python-focused runtime. My
comment was more about projects trying to retrofit Python on top of runtimes
that were built for very different languages, typically because of some
constraint that has now disappeared.

~~~
mixmastamyk
The GIL constraint has not.

~~~
toyg
If the GIL is so important to you that you're willing to suffer the pain of
running on another VM with a much-reduced ecosystem, while at the same time
having requirements so complex that PyPy cannot meet them, maybe Python is
just not the right tool for the project.

~~~
mixmastamyk
Moved the goalposts.

~~~
toyg
I am sorry that you see statements of fact and acceptance of reality as an
adversarial debate.

------
jondot
What I hate about this document is part of a bigger problem I see with the
Python community.

It's written like a hate letter with a passive aggressive tone of finger
pointing towards users of Python as the source of the never-ending Python 2-3
split. It says, between the lines: "YOU are part of the problem, stop using
Python 2. We don't care about YOU anymore. Stop using Python 2".

I can think of ten other different ways to be more constructive and,
generally, nice.

~~~
ausbah
It's been 10+ years, they're just being a matter of fact.

------
wepower_ico
I still see companies working with Python2 but I am happy for this
announcement - as it will make moving to Python 3 faster.

~~~
odiroot
Job security for us Pythonistas? Porting all this outdated code to Python 3.

~~~
truebosko
Totally. It's like getting a job in dated Java code bases. Tons of cruft to
support.

Boring work though

~~~
odiroot
Then automate. And still bill by the hour ;)

------
musicale
This would never have been such an unpleasant issue if Python 3 hadn't broken
backward compatibility in very annoying ways; one of the more inexcusable
examples was removing the print statement, a convenient piece of syntax that
dates to antiquity, and which could have peacefully coexisted with the print()
function in Python 3.

Now that Python no longer has a BDFL, maybe we'll get the print statement
back? ;-p

~~~
acdha
That’s something which takes literally seconds to safely fix across an entire
project using modernize/futurize, along with the better exception handling
syntax, etc. It’s just not worth clinging to the past at this point.

------
antoineMoPa
This should have been done in 2010. People will procrastinate 12 years if you
give them a 12 years deadline.

------
salamanderman
My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that
kind of subtle defaults that I think slowed the transition. I didn't want to
change the system Python.

~~~
pudquick
In 2016, that laptop also came with System Integrity Protection - you couldn't
change /usr/bin/python if you wanted to. And you still can't to this very day.
Changing System-provided python was always against recommendations in prior OS
versions because the next OS update could re-replace it at any time.

I agree that it probably contributed to python 2 inertia as it was re-exposing
people to the idea that "typing python in the Terminal gets me python 2" and
"I just used what I already had" \- but it definitely wasn't stopping people
installing a newer version.

~~~
CDSlice
Actually you _can_ disable SIP and replace use/bin/Python, but that is a Very
Bad Idea.

------
ericfrederich
I hope the Raspberry Pi community really switches to Python3 soon.

I've looked at the PiStorms stuff MindSensors (Lego Mindstorms compatible).
Unfortunately it all seems to be just Python2 based.

Looking at all the code it seems you're always basically running your own
event loop (infinite while True: loop). I think it'd be really awesome to
utilize Python 3's asyncio package to write more event driven programs.

Writing code in asyncio is basically a different paradigm. It's not like
Golang where you can write a function and not care if someone is calling it
synchronously or starting a goroutine with it. With Python asyncio it seems
for every good library out there someone has a create an asyncio version of
it. For instance "requests" vs. "aiohttp".

So, while embracing Python 3 still wouldn't get me what I ultimately want,
it's a first step in the right direction.

~~~
darpa_escapee
> _For instance "requests" vs. "aiohttp"._

"asks" implements a requests-like interface over asyncio/trio.

------
tams
With the sunset date passing, Python 2 is going to become a niche while still
having a massive install base.

There's a lot of money to be made doing migrations and keeping the beast
itself alive.

~~~
carapace
Yeah, that's my career for the next ~20 years...

I'm not complaining. I _like_ Python 2.

------
j-pb
And now remind yourself that there are self driving cars out there and
autonomous digging equipment that is based on ROS, which doesn't have any plan
or intent to move to python 3.

Fun stuff...

~~~
Ardren
ROS 1.1 (next release) will target Python3 only.

[https://discourse.ros.org/t/versioning-roadmap-
moveit-1-0-re...](https://discourse.ros.org/t/versioning-roadmap-
moveit-1-0-release-plan/7437)

~~~
j-pb
Thats not true, you're referencing the ROS wiki page of the MoveIt! Planning
package, which has nothing to do with ROS other than using it. Widespread
Python3 adoption is planned for ROS 2 which has been vaporware for the last 3
years.

------
perfunctory
People spend more time whining about the transition than it would take to _do_
the actual transition. Sigh.

------
johnlinvc
The battle has not over yet. RHEL 8 has Python 2.7 in their Application
Streams. So looks like Red Hat will provide security updates until Jun 2024
[https://access.redhat.com/node/4079021](https://access.redhat.com/node/4079021)

~~~
jabl
There was some mention somewhere that RH will support the python 2.7 appstream
for RHEL 8 as long as RHEL 7.x is supported. Which coincidentally is June
2024, so, yeah.

------
leowoo91
It's always good to see such big movements but as a truly peaceful p2 dev, I'm
not even considering to upgrade my projects unless it'd cost me labor not to
upgrade.

~~~
WilliamEdward
I mean this announcement is not a threat, it's a warning. After a certain
point there is diminishing returns on not upgrading.

------
mwkaufma
I would have loved to upgrade sooner, but I work in technical art and all our
tools are version-locked by native python extensions and QT5's compat. See
discussion at: [https://vfxplatform.com/](https://vfxplatform.com/)

I predict Maya devs (and, by extension, game engine vendors. like Epic/Unreal,
who version-lock to Maya's version) will stay on 2x well past 2020 by making
their own platform-compat patches.

------
darknoon
One of the more annoying aspects of the Python 2 to 3 transition is with large
movie / video production houses, eg Pixar. Their USD library only supports
Python 2, since they aren't interested in supporting Python 3. I wonder if
that will change next year.

The "industry standard" platform is only just getting around to switching to
Python 3: [https://vfxplatform.com](https://vfxplatform.com)

------
coliveira
That's why Python receives a bad name, and for a good reason. Nobody is
telling people who use Java since version 1 that they need to upgrade code if
they want to continue using the language. The code just works, and will
continue to work as long as there are compilers for Java. The same thing about
C and C++, these languages introduce new features as times evolve, but they
still allow users to retain their investment in old code. This is not the case
with Python. Because of some bad design decisions, they inflicted pain on
their users for more than a decade to force them into choosing one version or
another. And now they are deprecating a version of the language that is still
used by millions of people, causing again more trouble. Why in the world they
need to deprecate this code when there are millions of people who use it all
day long? I still see lots of code continuing to be written in Python 2, and
all this code will have to be rewritten just because of some bad design and
implementation decisions of a few people developing this language.

~~~
Lt_Riza_Hawkeye
>Nobody is telling people who use Java since version 1 that they need to
upgrade code if they want to continue using the language. The code just works,
and will continue to work as long as there are compilers for Java

This is the same with Python. Python 2 code will continue to work with python
2 interpreters, just as java 1 code will continue to work with java 1 JVMs and
JDKs. But neither are being actively developed and Oracle will not even sell
support for java 1, let alone release security updates.

~~~
gwbas1c
No

Typically version N+1 of a language compiles version N, N-1, all the way back
to version 1. Usually, when this isn't the case, the incompatible areas of a
language were either marked experimental, or obscure use cases that very few
people use.

Today's Java compiler will compile source code written for Java 1.

The issue with Python 2 and Python 3 is extremely unusual in a language.

~~~
ilikehurdles
I might be misunderstanding your comment, but I have encountered source code
that is not forward compatible in java. Some examples below...

Incompatibilities between JDK 7 and JDK 6:
[https://www.oracle.com/technetwork/java/javase/compatibility...](https://www.oracle.com/technetwork/java/javase/compatibility-417013.html#jdk7)

Incompatibilities between JDK 8 and JDK 7:
[https://www.oracle.com/technetwork/java/javase/8-compatibili...](https://www.oracle.com/technetwork/java/javase/8-compatibility-
guide-2156366.html#A999387)

An exerpt from the Compatibility Guide for JDK 8 [1]:

>In general, the source compatibility policy is to avoid introducing source
code incompatibilities. However, implementation of some Java SE 8 features
required changes that could cause code that compiled with Java SE 7 to fail to
compile with Java SE 8. See Incompatibilities between Java SE 8 and Java SE 7
and Incompatibilities between JDK 8 and JDK 7 for information.

There are also a plethora of deprecated and removed APIs throughout Java's
history.

[1]:[https://www.oracle.com/technetwork/java/javase/8-compatibili...](https://www.oracle.com/technetwork/java/javase/8-compatibility-
guide-2156366.html#A999097)

~~~
gwbas1c
Thanks for proving my point.

The incompatible areas that you explain amount to bug fixes and obscure areas
of the language. They aren't anything like Python 2 vs 3.

~~~
ilikehurdles
After seeing the months- to years-long process that enterprises have
undertaken when migrating from one JDK version to another because of these
"obscure areas", I have little empathy for anyone delaying a python upgrade
they've been given a 10+ year window for. Ruby 1.8 to 1.9 was similarly
painful to python.

------
Tempest1981
Last I checked, macOS doesn't include python3, just python2. I wrote a handy
tool for our team, but nobody uses it because they don't have python3. Now I
have to play sysadmin on dozens of machines.

A few had 3.5, but I used 3.6.

What can be done to make this easier? I.e. why isn't python3 pre-installed by
now? esp 3.6 or 3.7?

~~~
nvrspyx
Because Apple is notorious for using outdated libraries in macOS, like OpenGL.
They included Python, but it was never a real focus to stay up to date since
it was primarily to support legacy software.

With that said, Apple will not be including Python (or the other scripting
languages like Ruby or Perl) at all starting with Catalina.

------
jshowa3
Honestly it's about time. I've been annoyed at having to maintain two versions
of python.

------
wedesoft
Really difficult to track are issues caused by things like the map function
now returning an iterator object. I.e. the content of the iterator is empty on
second use.

    
    
      Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
      [GCC 4.8.4] on linux
      Type "help", "copyright", "credits" or "license" for more information.
      >>> x = map(lambda v: v + 1, [1, 2, 3])
      >>> list(x)
      [2, 3, 4]
      >>> list(x)
      []

------
kuu
I don't think the main problem is to change the version of Python, but the
version of all the related libraries, which many of them depend on 2.7
version.

I know many of the big ones are already on 3.x for a long time, but I wonder
how long will it take to replace and upgrade all the small ones if it did not
happen already...

BTW I don't know how necessary was to break compatibility between 2.7 and 3,
the pain of this transition comes from that decision

~~~
rlayton2
Any major library that hasn't moved to Python 3 by now isn't going to on their
own accord. Either that means they won't, or that the sunsetting will kick
them into gear (or get their users to kick them into gear).

It should be pointed out that Python 2 will continue to be used, and be
usable. It just won't get new security upgrades or features. I do not know,
but I doubt if there will be a feature or security flaw come up soon that
"forces" existing python 2-only libraries to update

------
brnt
Every now and then a language like no other pops up: it's use is unusual and
unusually long. Various biblical languages come to mind: Latin, Church
Slavonic, Hebrew at one point. These languages are feature complete, and the
fact that they didn't change was their main appeal.

I've always thought Python 2 might be headed for the languages. Which is fine,
it's great to have a programming equivalent of Latin.

~~~
jedberg
Latin is getting new words all the time. The Vatican is the official
maintainer. Sometimes it gets grammar tweaks too.

Hebrew was completely replaced with modern Hebrew and gets new changes
constantly.

~~~
edanm
> Hebrew was completely replaced with modern Hebrew and gets new changes
> constantly.

Just to clarify further, modern Hebrew is _mostly_ backwards compatible with
biblical Hebrew, it's not an entirely new language. It was mostly updated in
terms of vocabulary that was necessary for the modern era, plus some
spelling/grammar changes.

Modern Hebrew speakers are able to read biblical Hebrew almost completely,
though there are some differences (think of English speakers reading
Shakespeare - though even less difference than that.)

~~~
jsjohnst
Sounds like Python 3 (Modern Hebrew) vs Python 2 (Biblical Hebrew), no? Anyone
who can read Python 3 should barely struggle at all with Python 2. Anyone who
can read Python 2 will see a few tweaks in the grammar / functionality
(“vocabulary” in this analogy), but mostly straight forward.

------
carlmcqueen
This is good news for new users to python when getting books that start with
an argument for using 2 or 3 and then the book trying to be in both.

------
arendtio
Does someone know if there is a way to compile python programs to some sort of
static binary?

I have a GPS watch and some old Python 2 script to export the data (found it
online (unmaintained) a few years ago).

However, when Python 2 will be sunsetted I am a bit worried that Linux
distributions will stop packaging the dependencies of said script, but I would
like to keep using it until the watch breaks.

~~~
xd1936
You could give py2exe a try. They have an old python2 version that might work
for you.

[https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/](https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/)

~~~
arendtio
Thanks, sounds like what I am looking for, but sadly it doesn't seem to be
available for Linux :-/

------
jitl
At last...

------
ascotan
I wonder if there is an interesting lesson learned here for future language
maintainers.

One of the reasons for the 14 year deprecation windows (imho) is that the
language maintainers didn't have control over much of the core platform
libraries/ in everyday use. This created a lot of community angst against the
upgrade path.

------
vkaku
Wow. I still found some inadequacies with six, such as support for bytes/b,
datetime (timestamp) and SimpleHttpServer

Overall, didn't have too many issues with the conversion but this stuff is
going to hit some companies harder than others. I can tell that it's worth the
migration, end this blood fest once and for all.

------
dangxiaopin
I think the sunsetting is very premature. Python 3 became a stable and viable
alternative only since 3.6.1 (look at the evolution of async/await before that
for example). Giving it 2 years is definitely not enough for enterprise
(unless their focus is startup, tinkerers and data scientists)

~~~
AlphaSite
I mean, arguably they’ve been telling you too move for far longer. So it seems
reasonable to sunset it after 10 years.

~~~
dangxiaopin
So migrate a large production codebase to unstable API? With dependencies not
yet migrated?

~~~
partialrecall
Loads of open source and commercial projects have already made the switch to
python 3 years ago. If all of them could do it, so could your org. No excuses,
you've made your bed, etc.

------
speedplane
Python 2 to 3 comments can be boiled down to three constituencies:

1\. Native Python 3 Developers: It's great over here, what's the problem?

2\. Python 2 Developers Migrating a Small App: It barely took me any time, you
Python 2 developers are lazy and inhibiting progress!

3\. Python 2 Developers Migrating a Large App: Ugh.

------
Pxtl
11 years to make relatively small breaking changes. That's not a good sign for
future breaking changes.

------
eruditely
It seems everyday that history moves on, anyways this is a historic day and I
applaud the principal's for making a difficult decision. I wish them all the
best.

I've only used python for scripts and such and pandas for data-analysis at my
last job.

------
mistrial9
> We need to sunset Python 2 so we can help Python users.

We need to <specific goal> so we can <universal statement>. That statement is
boilerplate manipulative garbage.. its ok to speak this way because you agree
with the goal ?

~~~
rco8786
It’s certainly a meaningless statement, but I don’t think it’s manipulating
anyone

------
presidentscroob
Maybe Python 2 can go away soon. Also, modern Python 3 support isn't even
close to 100% either.

[https://pyreadiness.org/3.7/](https://pyreadiness.org/3.7/)

~~~
duckerude
That website is interesting, but maybe not as significant as it initially
appears.

In some sense chardet doesn't explicitly support Python 3.7, but it's packaged
for it in Debian Stable. I wouldn't expect any problems.

more-itertools is listed in white simply because it doesn't use any granular
version classifiers on PyPi. It only has a python_requires setting, which is
authoritative.

It's plausible that every single package on that page supports Python 3.7 in
practice.

------
swebs
When will OS vendors stop defaulting `python` to Python 2? It seems like an
unnecessary trap that pushed new developers to an out of date version. Even
Ubuntu 19.04 defaults to Python 2.7.16

------
hiccuphippo
I checked my system (Archlinux) a few weeks ago and the only things with
Python2 dependencies where the Gimp and Calibre. Kudos to everyone who has
worked on the migration over all these years.

------
jimmaswell
I'll never forgive the loss of the convenient print statement and easy string
handling. So much for "practicality beats purity." At least most of the other
new stuff is good.

------
rough-sea
Is there even a plan to transition the chromium code base to python3?

~~~
rough-sea
This issue is marked as wont-fix
[https://bugs.chromium.org/p/chromium/issues/detail?id=61357](https://bugs.chromium.org/p/chromium/issues/detail?id=61357)

Here is another issue which looks more recent and hopeful
[https://bugs.chromium.org/p/chromium/issues/detail?id=942720](https://bugs.chromium.org/p/chromium/issues/detail?id=942720)

------
m0zg
Meanwhile, TensorFlow build _still_ defaults to Python2. :-)

~~~
xenator
May be I didn’t noticed it. Pretty comfortable use it on python3 in my
environment. So, from my point of view, authors of the TensorFlow just need to
update documentation to complete transition.

------
sullyj3
The fact that ubuntu's (and by extension, most WSL installs') default python
is python 2 is crazy, and definitely not helping the situation.

------
Railsify
Finally. The transition is not hard, just time consuming, just split the work
among the team and force everyone to make a little progress each day.

------
acollins1331
Thank God. It's been really annoying having to add parenthesis to all the
print statements when I accidently download a python 2 script.

~~~
iwalton3
I've found that the 2to3 script will do this. The real pain is finding
everything that now has to be bytes instead of string.

~~~
someguydave
which is why python3 is dead to me.

------
sedatk
They took too long and that’s one of the factors making the sunset harder
today. They should have ripped the band-aid 10 years ago.

------
rolltiide
Python

Two distinct languages that happen to have the same name

------
formatkaka
Python 2 was the language through which I was introduced to programming. My
first love in this field !! Adios

------
Wheaties466
python 2 will continue to run on production systems for at least another
decade, thanks to centos6 and making it basically impossible to upgrade to
python3 as the main python binary on the system without completely breaking
everything.

------
Siecje
I'm curious which PyPI packages are preventing you from updating to Python3?

------
crb002
Guessing some Python 2 users rebel and fork to provide security patches.

------
sharperguy
Maybe now the Android AOSP build scripts will be updated to python3....

------
yters
If it weren't a forced update, I personally have not found much in Python 3
that is a benefit over 2. It seems the unicode support is the big change, but
I just use ASCII encoding, so unicode doesn't matter to me.

~~~
diminoten
> but I just use ASCII encoding

No you don't! :D

~~~
yters
Search for 'default'
[https://docs.python.org/2/howto/unicode.html](https://docs.python.org/2/howto/unicode.html)

~~~
diminoten
Thought you meant 3, not 2.

------
jrykbtest
Finally, print is no longer a reserved keyword!

------
CriticalCathed
Time for python 4. Python 3 to sunset in 2025!

------
zacky777
I still want to keep using Python 2.

------
lucaspottersky
sounds like they should probably sunset Python 3 instead

------
s_kunk
Protip: 2to3

------
lbj
Finally.

------
starpilot
rising

------
stefantalpalaru
We are volunteers who make and take care of a Python2 fork with backwards-
compatible Python3 features. That means we will keep on improving it without
breaking your code base or forcing you to hire the language creator and spend
more than 3 years porting your code to Python3, with no actual business
benefits.

[https://github.com/naftaliharris/tauthon/](https://github.com/naftaliharris/tauthon/)

------
charlus
Given we'll be at Python 3.8 next month, I can't help but wonder about Python
4. When it will happen, and how long.

~~~
coleifer
New features planned for python 4.0:

[http://charlesleifer.com/blog/new-features-planned-for-
pytho...](http://charlesleifer.com/blog/new-features-planned-for-python-4-0/)

~~~
toyg
You missed a /s there.

------
d--b
Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a
long time. Since the stuff is open source, wouldn't it be nicer if it was
possible to fix a bug if needed? Not saying that it should be actively worked
on. But maybe one person could be appointed to look over bug fix pull requests
(which shouldn't be that frequent these days).

~~~
VBprogrammer
As someone who works on a 99% Python 2 codebase I think this is a very
necessary step. Hopefully one of our larger customers will realise we are
still running their critical infrastructure on Python 2 and make enough of a
fuss that we can justify the expense.

~~~
melling
It was announced in 2014 that support was ending in 2020.

It seems a bit wrong to surprise a customer now.

~~~
VBprogrammer
We have a more complicated relationship with our customers than that implied.
Suffice to say they wouldn't actually be footing the bill.

------
tobr
I don't have a stake in this and don't know much about the background, so
pardon if this comment is out of touch. Is this the first notice of this date?
January 1 is just 16 weeks away, which seems like an awfully short notice for
ending security updates of a very popular language.

EDIT: I see now that they mention that 2020 has been the plan since 2014,
which seems reasonable.

~~~
raverbashing
If you read the article it was explained there, but tl;dr: it was announced in
2014 (that support would end in Jan 1st 2020)

~~~
rndgermandude
It was announced in 2014 that the sunset day would be further extended to
2020. The original sunset date was 2015, announced in 2008.

That's more than 10 years ago that the intention to sunset python2 at a
specific date was announced.

Anybody who, after 2008, started new, serious python2 projects that were
supposed to have a life expectancy beyond a few years was rather "optimistic",
and anybody who did after 2015 was almost callous, especially if you "played"
with other people's money.

------
anilakar
I wish Python Software Foundation had worded their announcement differently –
in the SW development context, even a plain "support for this version ends on
dd.mm.yyyy" sounds more professional and friendly than the word "sunsetting"
that has just too many negative connotations nowadays. From past experience it
usually means that a startup is pulling the plug or has outright gone
bankrupt.

~~~
Tom4hawk
I think you are in a startup echo chamber/bubble. Most of the world doesn't
have any negative connotations with that word. You cannot cater to everyone...

------
Stay_frostJebel
Kill it with fire!

Should have been removed years ago.

It actually causes real issues, such as build systems that only support
python2 but not python3.

The sooner python2 dies, the better. I need to use both python2 and python3
since otherwise quite several software projects refuse to compile from source.
An example is Mozilla's mozjs.

[http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h...](http://www.linuxfromscratch.org/blfs/view/svn/general/js60.html)

Also increases your trust in the company creating Rust when they are too lazy
to fix their whole build suite. Total clowns working at Mozilla here.

~~~
jsjohnst
> Total clowns working at Mozilla here.

Was the cheap shot really necessary?

