
Python 2.7 Countdown - mkesper
https://pythonclock.org/
======
sametmax
Let's take all a minute to thanks the awesome cpython team. Most of the devs
work on it for free. They have very little budget as opposed to corporation
backed projects like go, c# or js.

Yet.

The language has helped us since 5 years before java was born. You can find it
in websites like youtube and instagram, OS stacks like linux and mac, wall
street and NASA analytics, popular GIS, dropbox UI, blender and maya,
sublimetext...

Also thanks for having provided almost 15 years and many tools to migrate from
2 to 3. I know few languages that managed such a big update, but none that
gave so much to help with the transitions.

Guys and gals, you rock.

And it needs to be said because we hear the people complaining the most
loudly. Never all the people that are so grateful for it.

------
redsymbol
I teach online workshops on intermediate Python to several hundred developers
each month, scattered globally. Since these are engineers in the work force, I
start each class with a quick poll about which version they primarily use on
their jobs: 2.7, or 3.x.

18 months ago, the results were typically 20% Python 3, and 80% Python 2. Over
time, the ratio shifted. In recent months, it's VERY consistently 60-70%
Python 3; one class it was 80%.

As I tell those students: sooner than you think, having only Python 2 on your
resume will make it look dated.

~~~
Walkman
Who on Earth would write "Python2" in their resume? I have "Python".

~~~
redsymbol
I mean this in the kindest possible way:

You're taking what I wrote too literally, and thus missing the point. What I
wrote means: if the only Python you know is 2.x, it might close off
opportunities for you in the near future.

~~~
Walkman
Oh ok, that makes sense.

------
yegle
I took some time try to make an old codebase to work with python2/3\. Some wat
moment from the effort:

1\. `StringIO.StringIO` is a PITA. There's no equivalent in Python3 (for a
good reason), and you must choose between `io.StringIO` (which only support
unicode) and `io.BytesIO` (which only support bytes string). A possible
solution is to use `six.StringIO` but it's simply bury the problem. It would
be a good idea to think about what string you are dealing with before doing
any change around StringIO.

2\. The `stat` module contains some helper functions to test st_mode. In
Python2, the function will happily accept negative numbers but in Python3 an
exception will throw:

    
    
      $ python2 -c 'import stat; print(stat.S_ISDIR(-1))'
      False
      $ python3 -c 'import stat; print(stat.S_ISDIR(-1))'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      OverflowError: can't convert negative value to unsigned int
    

3\. You can do `def foo(a, (b, c), d)` in Python2:
[https://www.python.org/dev/peps/pep-3113/](https://www.python.org/dev/peps/pep-3113/)

4\. You can compare slice with int in Python2:

    
    
      $ python2 -c 'print(slice(1) > 1)'
      True
      $ python3 -c 'print(slice(1) > 1)'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      TypeError: unorderable types: slice() > int()

~~~
kstrauser
I think those are all improvements in Python3, even if they can be a hassle to
fix:

1\. Lots of legacy code incorrectly treats strings and byte arrays as the same
thing. If you're dealing 100% with all ASCII all the time that might be mostly
OK, but it's the wrong model for anything involving Unicode (which is pretty
much everything now).

2\. Modes are defined on Linux and macOS at least as uint32_t. -1 isn't a
valid value of that type.

3\. That bit me a few time. I've accepted that `def foo(a, b_and_c, d): b, c =
b_and_c` is an alright substitute.

4\. I like the new version better. `'a' > 5` doesn't even make sense and the
3.x way avoids accidental nonsensical comparisons.

------
Sir_Cmpwn
I made a similar, albiet more vulgar website a while ago:

[http://stfupy3.org/](http://stfupy3.org/)

~~~
tambre
Unaccessible over IPv6, unfortunately.

~~~
Sir_Cmpwn
This is hosted on GitHub pages, I don't think they have an IPv6 version. I
appreciate the irony in your statement, though.

------
rcarmo
My experience over the past year has been that 80% of what I need for new
projects is already available on 3 (with the remaining 20% being swappable for
other stuff), and that asyncio is a massive (if controversial) boost in
performance for some things.

I do wish that some of the gevent/Cython stuff was 100% compatible on
occasion, but it's manageable.

That said, 2.7 is still the default in many environments, and we're likely to
have to live with it for 12+ years.

------
paulgb
Is Python 3 an officially supported language at Google yet?

~~~
33degrees
As far as i know yes? Are there any services that don’t support it?

~~~
paulgb
I mean internally, as one of the "approved four" (Java, C++, Python, and
JavaScript, not counting Google's own languages)

------
Radim
_" …hereby suggesting we throw a massive party to celebrate all that Python 2
has done…"_

Perhaps it's that ominous counter, but these words really evoked Poe's "The
Masque of the Red Death" for some reason.

~~~
eesmith
I think of it more like a wake.

In "The Masque of the Red Death" they shut themselves away from the rest of
the world. There's no correspondence from that to the end of core developer
supported Python 2.

------
alergico
Guess the community (or a company like RedHat) will have to step in and fork
2.7. There is no way that people who haven't switched, will want to switch,
unless absolutely forced to (for example: no security patches).

~~~
guitarbill
This old chestnut. Yeah, if there's enough people who are willing to pay for
it (time or money), sure, Python 2.7 support will continue.

I just hope those same people have used the past years to do calculate the
cost of moving to Python 3 vs the cost of Python 2 support. Expecting Python 2
support to be free or even easy is delusional/selfish though.

~~~
hungerstrike
Pffft. Nice strawman. Who said it would be free or easy?

Expecting that everyone will just hop over Python 3 because one group of
people doesn't want to maintain Python 2 anymore is delusional.

~~~
kstrauser
At some point a CFO will ask why a company is spending $X to use ancient,
unhireable versions of their tools when new, free, attractive versions exist.
It will be explained - not exactly in these words - that it's basically
because their senior devs refuse to learn new stuff. Senior management
arguments will ensue. At the end, there will be a plan to save $X with One
Simple Trick.

Displaced senior devs will find themselves making nice paychecks at other
shops with obsolete codebases, at least until those CFOs start to notice a
funny line item in the engineering budget...

~~~
hungerstrike
Python 3 has been out for how long?

None of this has happened yet.

What is going to make 2.7 so unmaintainable? It’s there, it works and what is
going to change that?

~~~
kstrauser
Python 2.7 is currently supported. It's not a great idea, but at least
defensible, to still be developing against it today. But the moment it becomes
officially obsolete and shops have to justify paying special support contracts
to maintain it, I think it'll become very hard to explain why that's a good
business decision.

There are valid reasons for using 2.7 today. I think it's professional
negligence to not at least be planning for the inevitable upgrade to the
current version. Honestly, it's almost never as hard as you'd think. The most
common hurdles are str/bytes incompatibility, and 3.x only _reveals_ those
problems where they already exist in 2.x (where the code is quite possibly not
working as expected but silently passing wrong data without warning you).

~~~
hungerstrike
> But the moment it becomes officially obsolete and shops have to justify
> paying special support contracts to maintain it...

Who even pays for a support contract for programming language that’s already
done?

That’s like saying JavaScript is unusable because of all of the different
versions. Nobody has to pay anybody to use ES3 even though it’s largely
obsolete.

------
bhaavan
MacOS still ships with Python 2 as the default python.

~~~
Lev1a
AFAIK, Ubuntu does as well (if you mean that you have to write 'python3'
instead of 'python' to execute Python3)

~~~
r3bl
...up until 17.10.

Starting from 17.10, Python3 is the default one and the preinstalled one.

This switch kind of happened unnoticed because Ubuntu switched back to GNOME
at that version, but IMHO it is an equally important switch.

With 18.04, we should see that change having much greater effect.

------
FartyMcFarter
The big problem is that migrating to Python 3 can result in silent runtime
bugs.

Here's a scary case: [https://stackoverflow.com/questions/22288604/lambda-
function...](https://stackoverflow.com/questions/22288604/lambda-functions-
unequal-behaviors-in-python-3-and-python-2)

------
nas
For those still running 2.7 because migrating is too hard, consider using my
"ppython" version
([https://github.com/nascheme/ppython](https://github.com/nascheme/ppython)).
It is a modified version of 3.6 with extra backwards compatibility features.
After running your code through 2to3, it should mostly work with ppython.
After fixing all the runtime warnings, your code should work with regular 3.6.

------
jpz
f-strings were the killer feature for me - it’s a pity Python 3.6 isn’t in
Debian yet.

I do hope macOS get onboard next year also...

------
faragon
If there is Python 4, please, make it backwards compatible. Thank you.

~~~
eropple
A major version bump does tend to imply breaking changes.

~~~
faragon
Why?

~~~
eropple
What exactly does the term "major version update" mean to you if not for a
break in backwards compatibility?

That's what a major version update _is_.

~~~
faragon
How many mainstream programming languages do you know having equivalent issues
as Python 2.x to 3.x? Do you think it is reasonable to rewrite your code base
on every programming language "major version update"? One thing is deprecation
of features, because of not thinking an API properly back in the day, and
another, involving an important rewrite in order to get your code base
working.

My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding
breaking backwards compatibility. Just that.

