
Python 2.7 Retirement Countdown - yashmehrotra
http://pythonclock.org/
======
CJefferson
No, I'm getting sick of my code being broken.

My C code from 15 years ago works fine, but code in other languages can end up
breaking within a year. I've moved much of my development back to C++ just so
I can have reasonable confidence my code will work when I come back to it in a
couple of years.

I don't care if Python 2.7 never gains another feature, as long as my code
will still work in Windows 13 and Mac OS X 10.17.

~~~
Svenstaro
Your C code might still work but are you not relying on any libraries which
might have been updated in 15 years in a non-backwards compatible way and thus
broken your build?

~~~
CJefferson
It's not perfect, I'll admit.

I'm probably in a special area -- algorithms research. I tend not to use many
libraries, and I'm often taking code written 10-20 years ago and wanting to
get it working. The code is often VERY complicated, and I don't really want to
reimplement it.

Finally (and probably most importantly) I don't care about security holes, I'm
not going to run this code on malicious input.

------
dkarapetyan
This again? Python 2.7 is never going away, no matter how much people wish it
did. Python is the Cobol/Java of dynamic languages. There is way too much
volume of code written in it. This means there is a golden consulting
opportunity for those willing to take it: support 2.7 code/libraries for
money.

~~~
StavrosK
This again indeed, because Python 2.7 _is_ going away. Python 3 is the future,
and we've been resting on our "eh, python 2.7 is convenient enough" mindset
for too long. We should just bite the bullet and move to 3, which isn't even
that bad of a migration.

Also, "supporting legacy code for money" is already everyone's job, unless
you're implying that there are as many Python programmers as there are COBOL
ones.

~~~
bionsuba
That's incredibly naïve. Python 2 will be around and have new software written
with it for at least a decade to come. Keep saying "Python 3 is the future",
that will surely make companies invest in switching. Meanwhile ford still uses
40 year old IBM mainframes with COBOL, and will continue to do so until they
are physically unable.

~~~
cookiecaper
As others posters have commented, Python 2 will survive in the sense that
there will always be some code running on it (and there will be a niche market
for dark artists who can massage it). Python 2 will not survive in the sense
that no one will be writing _new_ code for it. Python 3 is already commonly
used for new projects and it's scheduled to get several big boosts in that
direction as Ubuntu and Fedora switch to it as the default Python.

The old meme that it's unsafe to use Py3 is not true anymore. Practically all
of the big libraries work fine on Python 3 now. Py3 code is going to be
dominant in new projects in short order if it isn't already, and it's
plausible that new Py2 projects will be virtually extinct by 2020.

------
fallenshell
Man, the amount of people and support going for Python 2.7 is mind boggling.
Coming from another language, I find the slow adoption of Python 3 insane.
Don't you want Python as a language to advance?

Python should've abandoned and deprecated 2 ages ago. I still see new
tutorials teaching 2. What the hell.

~~~
shadowmint
A lot of people really dont care about the future of python, they just want to
write code.

...and honestly, whats wrong with that?

really, what difference does it make if people use old python versions?

Other than the core python team, which get to be embarrased that many people
have zero interest in the work theyre doing?

Does it affect you? nope. Does it break the ecosystem? nope. Does it make
library authors suffer? nope (dont support it if you dont want to).

Come on. Live and let be.

If you love python3, use it. Dont winge pointlessly (not you personally; all
the hostile frothing at the mouth python3 advocates, especially on reddit)

~~~
asdfologist
I think you missed the whole point of this thread. People want ongoing
official support of Python 2.7, which involves resources that could be used
elsewhere. Supporting stuff is not free, you know?

~~~
shadowmint
[https://hg.python.org/cpython/graph](https://hg.python.org/cpython/graph)

I guess you can decide for yourself if the 'official support' of python is a
massive drain on resources that could be used else where.

(The red line with a few commits now and then is the 2.7 branch)

~~~
asdfologist
That's a lot of commits. You just disproved your own argument.

~~~
shadowmint
Oh please. It's a handful of backports and bugfixes. Actually read the
commits.

------
Grokzen
331/360 of the most popular repos on pypi supports py3
[http://py3readiness.org/](http://py3readiness.org/).

Also python 3 support is increasing, while python 2 support is decreasing
overall
[https://blogs.msdn.microsoft.com/pythonengineering/2016/03/0...](https://blogs.msdn.microsoft.com/pythonengineering/2016/03/08/python-3-is-
winning/)

~~~
kinkdr
Is the list correct?

It shows MySQL-python as 3.0 ready, but MySQL-python page
([https://pypi.python.org/pypi/MySQL-
python/1.2.5](https://pypi.python.org/pypi/MySQL-python/1.2.5)) notes:

> MySQL-3.23 through 5.5 and Python-2.4 through 2.7 are currently supported.
> Python-3.0 will be supported in a future release. PyPy is supported.

~~~
Grokzen
The tool they use to determine py3 support is the following:
[https://github.com/brettcannon/caniusepython3](https://github.com/brettcannon/caniusepython3)

They have overridden mysql-python with mysqlclient
[https://github.com/PyMySQL/mysqlclient-
python](https://github.com/PyMySQL/mysqlclient-python)

~~~
kinkdr
> They have overridden mysql-python with mysqlclient

I am aware of this, but the fact that the tool is reporting MySQL-python as
3.0 compatible, when it is not, is worrying.

~~~
neokya
Overrides are mostly for drop in replacement. So you could use mysqlclient but
chance very little in existing code.

------
altano
I just recently started learning Python for the first time, and at some point
I switched from playing with 2.7 to 3.x, and my uninformed opinion is that I'm
shocked at how many seemingly completely unnecessary breaking changes there
are.

Did the parameter names to open()d really need to change? Why did I have to
change from io.open() to open() for a stream? Did str.lowercase really need to
become string.ascii_lowercase? The number of errors in my toy little program
upon upgrading really surprised me.

~~~
forgottenpass
Python 3.0 was basically a line in the sand to throw in all these
"unnecessary" breaking changes. At the end of the day, no changes are actually
necessary.

But to keep Python improving without weighing itself down, some changes
couldn't just be slipped into the 2.x series. Because they're fundamental
enough changes to even effect toy programs.

So, yes, I'd say that the default string type did need to change from bytes to
unicode. And not only do I not miss str.lowercase, that kind of vestigial
feature is exactly the type of thing that should be purged with the unicode
transition.

------
iconjack
Well I'm sure this is a naive point of view, but I'm going to put it out there
anyway. It seems there are many Python devotees out there who are lukewarm
about Python 3, and quite a few who really don't like it at all, hence a slow
adoption rate. Right now it seems like the community is fractured along that
fault line.

Is it too late? Can we back out of the current incarnation of Python 3 and go
down another path instead? In other words, turn the slow adoption rate into a
plus, call a do-over and mold the new Python into something more people are
happy with.

~~~
nerdponx
As someone who learn Python 3 first, I'm amazed that people really think
Python 2 is better.

After so many years, why the resistance?

~~~
iconjack
I hope you didn't read my comment as saying Python 2 is better. Personally I
don't have an opinion on that. But as you can see from this thread and many,
many others, a lot of people are disappointed with Python 3's choices. You're
right, it's been a lot of years, but if adoption has been as slow as some are
suggesting, maybe we could cut our losses and put our beloved Python on a
different path, as a community.

~~~
nerdponx
Maybe, but at the same time I haven't yet seen a criticism of py3 that wasn't
just a litany of complaints about backward compatibility. Even in this thread,
I don't see a whole lot of substance behind the discontent.

------
coldtea
Yeah, don't hold your breath.

------
jgalt212
Most everything good from Python 3 has been back-ported to 2.7. Except for
built in parameterized tests in unittest.

Python 3 has the subTest context manager (which looks great)

[https://docs.python.org/3/library/unittest.html#distinguishi...](https://docs.python.org/3/library/unittest.html#distinguishing-
test-iterations-using-subtests)

In 2.7 you must use pytest, ddt, nose-paramemterized or dynamically add test
methods to a TestCase class at runtime.

~~~
scrollaway
Most everything good? Like high quality unicode support and async def?

~~~
Avernar
High quality unicode? Where every string with even a single emoji takes 4
times the memory. They should have used UTF-8 for their internal
representation.

Putting that aside, my issue with 3.X is that I have to use the unicode type
even when I'm manipulating byte strings.

~~~
scrollaway
> even when I'm manipulating byte strings

What? No you don't. The `bytes` object is what you want when you deal with
byte strings.

~~~
Avernar
The bytes object is not a string type. It's treated more like a list of
integers. It has very little string operations. Only in 3.5 did they add back
the ability to % format.

Not to mention all the b prefixes it just becomes painful.

------
Scarbutt
Don't really like the tone of this, they are resorting to psychologically
tactics now? (btw, I'm all in for pushing Py3)

~~~
Bromskloss
Might this not simply have been made by someone who is tired of having to deal
with Python 2?

------
asdfologist
People here keep bemoaning the golang designers' decision to not upgrade their
language with things like generics, but suddenly their panties get twisted in
a bunch when the Python community actually decides to fix problems in their
language.

Get off your high horse and upgrade your code. So many people did it before
you, and so can you.

~~~
netheril96
If Go upgrades itself with support with generics but break backwards
compatibility in a horrible way and the breaks cannot be caught at compile
time, people will be complaining and resisting upgrade just the same.

~~~
Retra
And what should the Go team do if the only reasonable way to add generics is
to break backward compatibility? Just rip the bandage off? Stagnate? Abandon
the language and start a new one?

~~~
zzzcpan
Programming languages are not like that. There is an unlimited amount of ways
to implement a feature without breaking backward compatibility. Perl, for
example, at some point kept compatibility even with bugs, because many people
were relying on them.

~~~
Retra
I don't understand this at all. Yes, you can add features, but if they are not
ergonomic, then why bother? For instance, you can't just add features that
introduce syntactic ambiguity or change your parser to become context
sensitive without making the language significantly more complex all around.

Yes, you _can_ add anything without breaking backward compatibility. That's
why I qualified it with "reasonable" \-- there are very good reasons to break
backward compatibility, and being a slave to it will pile up technical debt in
very unpleasant and potentially avoidable ways.

It's like trying to make a skyscraper taller without rebuilding the
foundation. Sure, you can add giant ugly supports on the side, but once you've
done that a few times, nobody is going to feel safe near your building. And no
self-respecting architect would do it.

~~~
zzzcpan
There is nothing stopping you from implementing a feature in a reasonable and
ergonomic way without breaking backward compatibility. Programming languages
are fun like that. Anything can be done, your imagination is your only limit.
And on this level technical debt is not a concern, not even a little. But
having good rationale for a feature is, and a huge one. Most of the time the
authors themselves don't know why they need it, they just feel like having it.

------
DasIch
There are enough large organizations using Python that no doubt at least one
will find it to be cheaper and more convenient to continue maintaining a 2.7
interpreter. Dropbox is working on one just to increase performance. PyPy also
has due to how it works fundamentally a huge interest in maintaining Python
2.7 support for the forseeable future.

You've to be quite naive to believe that Python 2.7 will retire in 2020. It
will only fade from popularity slightly faster.

~~~
sandipc
Guido van Rossum (Python BDFL) himself works for Dropbox, so I'm not sure I
believe that...

See also:
[https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...](https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.pptx)

~~~
DasIch
He does but how much influence does he really have there? I doubt it's enough
to push them to 3.x just because. Pyston 0.5, the interpreter developed at
Dropbox, was also just released a few days ago.

They're going to do what's pragmatic and cost efficient. Making everyone stop
improving the product and porting the code base, is probably more expensive
than just having one team maintaining and improving the interpreter.

------
unlinker
3 Years 10 Months 13 Days 20 Hours 54 Minutes 31 Seconds until a community
fork occurs.

~~~
underyx
Actually, it seems to me that everyone who is active in the community is
already on Python 3 and is heavily in favor of upgrading.

The people who are still using Python 2 are the 'lazy' ones, who don't really
care about the community at all; the ones who keep making comments like 'I
just use whatever the `python` command starts.' I'm pretty sure these people
couldn't maintain Python 2 by themselves.

~~~
wink
I have a reasonably large project that was started in late 2013 (so only 2.5
years ago) when 2.7 was already long "to be deprecated" but some of the key
libraries used were not yet python 3 compatible.

I haven't actually checked, it could probably be ported now - but why would
you do that _now_ \- everything can change in the next 3 years.

~~~
takeda
We're over the hump if something would change and still was python it would
most likely be compatible with python 3.

There two things that might help you port things:

1\. You can use Cython to mix python 2 and python 3 code together. You compile
python2 code as a module and then reference it from the python3.

2\. MyPy ([http://mypy-lang.org/](http://mypy-lang.org/)) - This might not
seem like related, but if you provide information about types refactoring the
code becomes much easier (like in statically typed languages) so when you
change something it's easier to find all other places that also need to be
changed. Some IDEs (for example PyCharm) also understand typing which helps
when using their refactoring functionality.

------
Animats
The amount of effort Python puts into screwing 2.x users is excessive.

~~~
afarrell
It's not that maintainers want to screw anyone over, it's that folks who give
away labor for free to maintain libraries want to be able to use the new
features in 3.x without spending additional unpaid labor to maintain separate
2.x versions.

~~~
kinkdr
And vice-versa, it is not like users have some grunt against developers. They
just don't want to go through the pain of having to migrate their applications
and the instability that this will bring.

(Disclaimer: I am not supporting any side)

~~~
mfisher87
Why does end-of-life mean you __have __to migrate your application? 2.7 isn 't
going to just go poof and self-destruct on your computer.

~~~
kinkdr
I am not following.. Using the same logic they could have stopped support for
2.x the moment 3.0 was released.

~~~
afarrell
But they wouldn't be able to say "you should use python, we have all of these
libraries!" Now, they can. There are a bunch of libraries that run under both
2.7 and 3.5, but they are doing extra work to make sure they work under both
codebases and they are refraining from using any of the nice features of 3.5

------
omash
I'm hopeful we'll abandon Python 3 instead.

~~~
Bromskloss
Do you like Python 2 better than Python 3?

