
Numpy: Plan for dropping Python 2.7 support - AndrewDucker
https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst
======
fredley
Good. The glacial migration from Python 2 to 3 is one of the worst things
about an otherwise _fantastic_ ecosystem. The tide is turning though, with
Django having already dropped support for 2, and now with Numpy too hopefully
Python 2 can be properly consigned to the history books.

For people wondering why it's been like this for almost a decade(!) since
Python 3.0 was released: Python 3.0 was actually terrible. It lacked many
critical things, and was riddled with bugs and security flaws until 3.3, which
was released _4 years_ after 3.0. This cemented in many people's minds the
idea that Python 3 was a bad thing. Python 2 was and is a fantastic
programming language, so it was a very high bar to move up from. Python 3 has
come a long way since then, Python 3.6 is now a decent step up from 2.7.

~~~
Figs
Frankly, I _still_ haven't seen a single reason to switch to Python3 beyond
the fact that the original authors have gotten bored of providing security and
bugfix updates and will stop in 2020. That's it.

The only thing in the last decade or so of Python3's existence that even got
me slightly interested in using it was asyncio, and after looking into it a
bit, it frankly seems like more trouble than its worth.

I know Python 2.7 extremely well. It works perfectly fine for just about
everything I use it for. It's STABLE. For the tasks I use it for, it runs
_faster_ than Python3... (Not that performance is my greatest concern when
using Python.) So, please tell me -- why on earth is it a good thing that
people are trying to kill off Python2? What exactly makes Python 3.6 a "decent
step up" from 2.7? I'm still at the point of thinking, as you said, that
Python3 is a bad thing.

~~~
crusso
_why on earth is it a good thing that people are trying to kill off Python2?_

Because the community is fragmented and that weakens language adoption,
productivity, and enjoyment.

The 2-3 schism in Python has been a pain to deal with for years. I use Python
casually here and there, but I'm so sick of trying to do something quickly in
Python and finding out that I'm on a machine that only has 2 but the module I
need is only for 3 or having the bulk of my app written in 3 but the only
version of a module I need is for 2.

Same goes for examples you find on the Internet to do a particular thing.
Ooops, it's 2.x syntax/modules so you have to fix it up for 3. Ooops, it's 3
syntax/modules so you have to fix it up for 2.

For the good of any computer language, old versions need to eventually die
off.

~~~
cpncrunch
>For the good of any computer language, old versions need to eventually die
off.

I would say instead: for any good computer language, new versions need to
retain compatibility with old versions. Every single system I run has python
2.7 (including my brand new Macbook running latest OS X). Luckily I don't need
numpy, and I can probably do without python at all if I have to.

Compare to perl: I can run old perl scripts on basically any system without
having to worry about it breaking. I do all of my server scripting in perl for
this reason.

~~~
cyphar
Perl6 is incompatible with Perl5, so they're also going through a similarly
painful transition.

Everyone waxes lyrical about how Python 2.x was "good enough and why would you
change it", but there were several things in Python 2.x that were objectively
awful (unicode was broken, iterator variables can leak to the outer scope,
division of integers producing integers, xrange, raw_input, mixed indentation
"working", etc). And while no single issue alone would justify Python 3.x, the
combination of all of these issues as well as some other semantic problems
justified the need for Python 3.

Of course, that being said, Python 3 also had some issues that it took several
versions to iron out.

~~~
setzer22
I am wondering. Why is division of integers returning an integer an _awful_
thing?

~~~
cnvogel
[https://www.python.org/dev/peps/pep-0238/](https://www.python.org/dev/peps/pep-0238/)

{Describing the old python-2 behavior:}

\-------- Quote: -------

The classic division operator makes it hard to write numerical expressions
that are supposed to give correct results from arbitrary numerical inputs. For
all other operators, one can write down a formula such as x _y_ *2 + z, and
the calculated result will be close to the mathematical result (within the
limits of numerical accuracy, of course) for any numerical input type (int,
long, float, or complex). But division poses a problem: if the expressions for
both arguments happen to have an integral type, it implements floor division
rather than true division.

\-----------------------

To guarantee the correct mathematical behavior in python2, one would probably
have to write:

    
    
        def true_math_div(a,b) :
            if type(a) is int or type(a) is long :
                a = float(a)
            if type(b) is int or type(b) is long :
                b = float(b)
            return a/b
    

as a and b could be int, float, complex, or some object defining the method
__div__.

~~~
majewsky
What's wrong about just `float(a)/float(b)`?

~~~
dagw
not everything that can be divided can be reasonably cast to a float

~~~
OOPMan
Also, it's ugly as sin

------
BoppreH
To preempt the inevitable discussion of which version to use, please refer to
the amazing FAQ created by Eevee: [https://eev.ee/blog/2016/07/31/python-faq-
why-should-i-use-p...](https://eev.ee/blog/2016/07/31/python-faq-why-should-i-
use-python-3/)

As a library writer, I cannot wait until we get rid of this self-inflicted
handicap of writing in a subset of two incompatible languages. I'm glad the
heavyweights are joining the cause.

------
rectangletangle
This is great news. I've been working with Python 3 for a few years now, and
it really is a nicer language than 2. Granted 2.7 is a hard act to follow.

Even though the transition from 2 to 3 has been slow, I take it as a positive
sign about the Python ecosystem. The general Python community has
traditionally erred toward stability, and conservative feature introduction.
The gradual introduction of large changes to the core language reflects that
characteristic.

Hopefully this will cajole Python 2.7 users to migrate. Assuming you have
decent test coverage, the migration generally isn't _that_ difficult.

If you do a lot of NLP or string processing, the sane unicode support is worth
it alone.

------
pletnes
That’s about the same time python 2 support drops in general. Sounds strange
to support packages after the underlying python has moved on.

Kudos to the numpy team for writing the most awesome python module under the
sun, and for providing great support!

~~~
jwilk
It's not strange. Python developers might declare Python 2.X EOLed, but that
won't stop people from using it. Like it or not, Python 2.X is not going away.

~~~
freyr
There are big companies with huge legacy 2.x codebases who will stall as long
as possible. But popular libraries are dropping 2, and many new libraries
aren’t supporting it to begin with. Python 2 is accelerating toward
irrelevance.

~~~
greymeister
You make it sound like they're holding out of some weird sense of spite. It's
more reasonable to assume most large or small companies still using 2.x have
not prioritized upgrading over, I don't know, staying in business?

As large libraries drop 2.x support over time they'll have to prioritize
upgrading.

~~~
jhall1468
> have not prioritized upgrading over, I don't know, staying in business?

Banks use the very same excuse for a long time, which is why they can't even
find Cobol devs to do the work. Bottom line: if having some new grad developer
convert Python2 to 3 for some legacy shit would put you out of business,
you're already well on your way out.

------
rossdavidh
At the SciPy 2017 conference, for the first time I saw speakers who were
presenting new libraries say that they were not going to be developing Python2
versions. Quite a change from a year or two ago.

~~~
StavrosK
All my libraries have been py3-only since around last year. I'm also not
caring much about supporting 2 on the old ones I maintain. 2 is pretty old,
it's time to move on.

~~~
username223
> 2 is pretty old, it's time to move on.

Why? Just because "it's pretty old?" The 2-to-3 change seems mostly cosmetic.
When Python users ignored 3, Python devs started flogging their dead horse.
When the horse still refused to move, disappointed riders started shouting
"shame!" at users who suggested that the horse looked dead. Eventually, the
riders tied ropes to the horse and pulled it along the ground. The onlookers
either switched to bicycles and cars, or figured that they might as well ride
the man-hauled carcass awhile longer.

~~~
dwb
That's a very melodramatic comment for someone who clearly hasn't been keeping
track of the 3.x changelogs – which pretty much all contain at least one
compelling update to the language. Modern Python is v3. Legacy support drop-
off is the same with any project.

~~~
username223
I was going for "humor" more than "melodrama," but maybe I failed at both...
The actual breaking changes between 2.x and early 3.x struck me as cosmetic
and pointless.

To compare: Perl went one way by breaking everything to essentially make a new
language, and failed to get people to switch; C++ bent over backwards to
maintain compatibility, and failed to fundamentally evolve the language.
Python basically failed in both ways, changing the language just enough to
break most people's code, while changing it too little to effect significant
change. It combines most of the disadvantages of both backward compatibility
and novelty, with few of the advantages of either.

~~~
rspeer
To also compare: Ruby made big breaking changes similar to Python 3 and called
it "Ruby 1.9".

It wasn't really a big deal. There was some pain and it became essential to
have multiple versions of Ruby installed. But I haven't heard of anyone
insisting on new code written for Ruby 1.8.

So languages _can_ break backwards compatibility once in a while, and it
doesn't always have to be the shitstorm it was for Python.

Early 3.x was bad, and that probably gave critical mass to the backlash. But
there's no reason to care anymore about what early 3.x was like. Modern 3.x is
a way better language.

~~~
username223
I was an outsider to the Ruby changes between 1.8 and 2.0, so thanks for the
perspective. My sense was that, like modern JS programmers, they were used to
constant churn and breakage, so having the language break as well was only a
minor additional nuisance. Most of the stuff they used with 1.8 would be
"obsolete" in a year or two even without 1.9.

~~~
bhaak
Your view of Ruby programmers might be confused with Rails programmers. Those
are more used to the "constant churn and breakage" which I also see as coming
somewhat from the web side of programming. Although it's less of an issue in
Rails as you can have properly stickied versions in a project.

AFAIK there was no breaking change in Ruby after 1.9, so anything that runs on
1.9 should run on any Ruby version up to the most current.

The biggest change in 1.9 was the support of different encoding and making
UTF-8 the default encoding. Ruby did it differently than Python, so a string
in 1.8 was a byte string, whereas a 1.9 string was a UTF-8 string. This off
course broke many scripts.

------
Pxtl
After such a long and painful road from 2 to 3, I feel like the Python
developers aimed too low in fixing the legacy problems that existed in 2.

All that time for Unicode. Not concurrency or type safety or static guarantees
or better lambda syntax or anything fun like that. Just Unicode.

~~~
Ivoah
> better lambda syntax

What do you mean by better lambda syntax? Is there something that you feel
isn't adequate in the current syntax?

~~~
bastawhiz
It's a bit verbose. A lambda with a single one letter param takes ten
characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take
sevenish: `{|x| }`. Six in haskell.

~~~
tome
How did you get six for Haskell? I get five if you require a space at the end

    
    
        \x->

~~~
bastawhiz
I was counting a space after the x.

------
reggieband
I cheered Python's slow and steady 2.7 -> 3 move when it began but I'll admit
I started to have some doubts a couple of years ago when it still had not
completed. In hindsight I think it has been exceptionally well managed and is
likely to keep Python in good stead for many years to come.

------
mattbillenstein
* at the end of 2019

I guess it's due -- Python 3 finally has some improvements to the runtime that
I think will start to pull more Python2 people over.

~~~
boulos
Their plan is more nuanced than "at the end of 2019". From a numpy _feature_
standpoint, it's EOY 2018, bugs through EOY 2019:

> Until December 31, 2018, all NumPy releases will fully support both Python2
> and Python3.

Starting on January 1, 2019, any new feature releases will support only
Python3.

The last Python2 supporting release will be designated as a long term support
(LTS) release, meaning that we will continue to merge bug fixes and make bug
fix releases for a longer period than usual. Specifically, it will be
supported by the community until December 31, 2019.

------
nonbel
I am a python outsider, but like many others dealt with a lot of pain due to
the simultaneous 2 and 3 versions.

Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7.
Based on this the current python 3.6 seems to be nearing end of life.
[https://en.wikipedia.org/wiki/History_of_Python](https://en.wikipedia.org/wiki/History_of_Python)

So what will happen when python 4 comes out?

~~~
rspeer
The Python developers plan to never break syntax or stdlib compatibility
again. Core developer Nick Coghlan wants to see 4.0 within the decade but he
wants it to be "uneventful". [1] In that way, it would be a lot like Python
2.0, which only broke compatibility in obscure ways, but added new ways to do
things.

Here are some of my wild guesses at what features Python would want to
commemorate with a 4.0 release:

\- An easy, Pythonic way to opt out of the Global Interpreter Lock. (The GIL
clearly isn't going away because so much extension code needs it, but that
doesn't mean _all_ code has to suffer from the GIL for eternity.)

\- UTF-8 as the guaranteed default encoding, instead of trying to infer
anything from stupid locale shit. (This wouldn't break any code that wasn't
broken already.)

\- More built-in syntax to support NumPy.

[1]
[https://www.curiousefficiency.org/posts/2014/08/python-4000....](https://www.curiousefficiency.org/posts/2014/08/python-4000.html)

~~~
int_19h
> UTF-8 as the guaranteed default encoding, instead of trying to infer
> anything from stupid locale shit.

This is already the case for source code, right? And I don't see where else it
could apply. If you mean stdin/out, then those have to use locale to be
compatible with other text-processing software (so that you can pipe things
etc).

~~~
rspeer
Locales are not a real way of specifying an encoding for standard in and out.
They were not designed for a world with Unicode and UTF-8 in it; they were
designed for a world with limited character sets where your text data would
probably not be sent outside of your country.

Here are some reasons not to try to get your locale to tell you about UTF-8:

\- There is no standard for this.

\- Locale suffixes ".utf8" and ".UTF-8" are hacks by specific Linux
distributions, and people want their Python code to work _even if their system
has not implemented this hack_.

\- The locale "C" does not _really_ mean you want your program to explode when
it sees a non-ASCII byte. What Python does here does not promote compatibility
in any way.

\- BSD has no UTF-8 locales and has never pretended that locales work with
Unicode.

\- Windows' equivalent of locales is extremely deprecated and never actually
supported UTF-8. The modern Windows APIs that deal with standard in and out
correspond to Python's Unicode string type, not its bytes type; encoding the
Unicode I/O into bytes is not Python's responsibility.

\- Really every operating system but Linux has this figured out, and in
practice, Linux users want UTF-8 _regardless_ of what their locale says.

To be compatible with other text-processing software in 2017, you don't use
locales, you use Unicode APIs and UTF-8.

~~~
int_19h
> Locale suffixes ".utf8" and ".UTF-8" are hacks by specific Linux
> distributions, and people want their Python code to work even if their
> system has not implemented this hack.

I do want my Python code to work, yes. But I assure you that if my locale says
ru_RU.KOI8-R, when I say "work", I don't mean "dump garbled stuff on my
screen, because you output UTF-8 when I specifically asked you to use KOI8-R".

I also don't see why the UTF-8 encoding specifier in locale is a "hack". UTF-8
is just that, an encoding. Locales are a generic mechanism for dealing with
encodings. What makes UTF-8 special in that regard, and why is an UTF-8 locale
a hack?

> The locale "C" does not really mean you want your program to explode when it
> sees a non-ASCII byte. What Python does here does not promote compatibility
> in any way.

That's true for any locale, if a character comes up in the output that cannot
be encoded in it - it should just use some reasonable substitution. And if
you're _actually_ dealing with binary data, then you should be reading and
writing bytes objects, not printing strings, and then the whole question of
encoding is moot.

> BSD has no UTF-8 locales and has never pretended that locales work with
> Unicode.

That would be a surprise to my FreeBSD installation, which is running with
en_US.UTF-8. Do you mean that the locales don't come generated by default? I'm
not sure why it's a big deal ... I mean, Arch doesn't come with _any_ locales
generated by default, but I don't think anyone would claim that it doesn't
support UTF-8.

One other thing BSD does, is that it doesn't guarantee that wchar_t is Unicode
in all locales (Linux/glibc does). But that's a different and orthogonal
issue.

> Windows' equivalent of locales is extremely deprecated and never actually
> supported UTF-8. The modern Windows APIs that deal with standard in and out
> correspond to Python's Unicode string type, not its bytes type; encoding the
> Unicode I/O into bytes is not Python's responsibility.

Win32 doesn't have any string-based I/O functions, except for console. So if
you're printing directly to the screen (and ignoring / not supporting
redirection!), then yes, you can just invoke WriteConsole, give it a UTF-16
string, and be done with it. But if you're printing to a file, or to stdin/out
as a handle, then you only have ReadFile/WriteFile, which require a byte
array; you're expected to do your own encoding.

By the way, and speaking of proper Unicode handling APIs - because of this
disparity, and the desire to avoid a conversion unnecessarily (due to the lack
of UTF-8 locale making it lossy) so as to allow printing out Unicode, Python
actually has to resort to hacks to do this on Win32. Specifically, it has a
special class - _io._Win32ConsoleIO - that is implemented using
ReadConsole/WriteConsole. If output is a Win32 console, then that class is
used, and Unicode is fully supported in the output. If output is redirected,
then the standard implementation (that does encoding + Read/WriteFile) is used
instead.

> Really every operating system but Linux has this figured out, and in
> practice, Linux users want UTF-8 regardless of what their locale says.

I strongly disagree. The users who want it but don't know how to configure it,
are already using a distro that says that it should be UTF-8. The users who
are using something that doesn't, either do it for a reason, or are
knowledgeable enough to know what's going on and why, and deal with it
accordingly. Either way, no harm is done by just using the locale setting. On
Ubuntu etc, it will just be UTF-8, and everyone will be happy.

~~~
rspeer
> Locales are a generic mechanism for dealing with encodings. What makes UTF-8
> special in that regard, and why is an UTF-8 locale a hack?

Locales are a generic mechanism for dealing with code that should run
differently in different countries. There have been other HN discussions
recently about why this is terrible in the present day. Encodings are just one
aspect of that.

The whole thing where you name a locale, then put a dot and tell it what
encoding you _really_ wanted, is what I'm referring to as a hack. There is no
standard for locales with dots in them. But the locale system was created at a
time when, say, the US was using ISO-8859-1 and Poland was using ISO-8859-2,
and this was just a fact about how you had to deal with text.

But that's exactly what Unicode got rid of! You don't make Unicode decisions
by country (with terribly awkward exceptions such as Japan, where Unicode
itself is unpopular, and Python is too). It's not like the US uses UTF-8 and
Canada uses UTF-16. You make Unicode decisions based on the OS and APIs that
you're interacting with. And that's why we have this Linux dot convention for
overriding what the locale would otherwise say so we can use Unicode.

So your recommendation to use locales is actually a recommendation to mostly
ignore locales, and just use the part after the dot as the name of the
encoding you should be using. And to make wild-ass wrong guesses if there's no
dot. Taking the locale "C" and interpreting it as the encoding "ASCII" is an
example of a wild-ass wrong guess.

But there are already environment variables that configure Python to use a
particular encoding, without hacking it on top of archaic shit like locales.

And harm _is_ done by trying to infer the encoding from the locale, because of
the complete wrongness of assuming the "C" locale means to use Python's
"ASCII" encoding. The resulting behavior is not correct, and the reasoning for
it is not correct. It's a bug. It will probably be fixed in one of the next
two versions of Python.

People run Python from cron jobs, from IDEs, from all sorts of places that
don't set the locale the way the Ubuntu shell does, and get bafflingly
inconsistent results. You can say "fix your locales then" all you want, but
this is not an answer that makes Python more usable, and the developers have
acknowledged this.

Here's a particular example of where I think you're coming at this from the
wrong direction, where I think you're taking the current behavior of Python as
if it were actually some sort of intentionally-designed standard:

> That's true for any locale, if a character comes up in the output that
> cannot be encoded in it - it should just use some reasonable substitution.
> And if you're actually dealing with binary data, then you should be reading
> and writing bytes objects, not printing strings, and then the whole question
> of encoding is moot.

You don't encode things in a locale! You encode things in encodings! I'm
definitely not talking about binary data, I'm talking about printing out
_perfectly normal_ characters like "ü".

The locale "C" does not tell you _anything_ about what encoding to use. Which
is very different from Python's current assumption (which may go away in 3.7)
that it's telling you to use ASCII and explode.

~~~
int_19h
This really has nothing to do with Python per se. Python should do the exact
same thing that C does, which is to say, what mbstowcs and wcstombs do. And
those do "infer" encoding from locale.

I agree that the conflation of encodings and locales in Unix is rather
unfortunate, but, again - nothing to do with Python. On Unix, Python should do
what well-behaved Unix apps do, for the sake of consistency and
interoperability.

------
obblekk
One of the early principles of python was there is one idiomatic python way of
doing it. Usefully, this enforced a world-wide code style guide, making it
easy to read python code.

2.7 and 3.x essentially forked the language, enabling different idiomatic ways
to do the same thing which reduced this particular advantage of python. I'm
looking forward to seeing the community merge up again.

------
knlje
I'm a researcher and have used exclusively Python 2.7 and NumPy for many
years. Originally I ported my codebase from Matlab to NumPy because I wanted
to go open source. But it's a very nice thing in science if your code runs
perfectly for many years. You don't want to do rewrites. So I feel like I
should have stayed with Matlab.

Now that I'm soon forced to do another rewrite, I think I'll just switch to a
different language with better future prospects on backwards compatibility. I
don't feel that I can trust Python anymore in such things. Any ideas?

~~~
interrrested
It is a bit weird to want better support. Version 3 is out for so many years
already.

Have you dropped using windows when XP is not supported anymore ?

~~~
quietbritishjim
Not a great analogy: Programs designed for Windows XP, or even as far back as
Windows 95, still run on current versions of Windows. Support for 16-bit
programs (from the era of Windows 3.0, released in 1990) started to be dropped
in Windows 7 64-bit, and even that included "Windows XP Mode" so they could
still be run.

------
4lch3m1st
Let's hope this move helps with the transitioning to Python 3. I'm not a
Python programmer myself, but I'm tired of things getting hairy on Linux
dependencies written in Python. It almost seems like I always got to have a
Python 2 and a Python 3 version of some packages so my system doesn't break.

------
ben_w
I hope Apple takes this as a reason to upgrade the default Python version
installed on OS X, otherwise this could be a needless headache.

~~~
x0x0
virtualenv plus virtualenvwrapper makes this really easy... using a virtualenv
can be as easy as

    
    
       workon #{projectname}

~~~
untog
Yes, but it's great to be able to use Python for simple scripting tasks too.
In that context it's way too much to expect a user to download virtualenv, so
instead people just write things for 2.x

~~~
urda
You can still install just python3 and call that as-is if you are not using
any extra libraries.

If you are using any extra libraries, you should not be installing that
system-wide, and should use an environment anyway.

You literally can still use python3 for simple scripting tasks on your Mac,
hell I do everyday. One just has to install python3, a trivial task on a Mac.

~~~
x0x0
homebrew will install pip3 along with python3; on my install, python3 packages
go in /usr/local/lib/python3.6/site-packages while python (2.7) packages go in
/usr/local/lib/python2.7/site-packages . I can't understand the complaint
except for having to type 3 I guess?

------
pdknsk
I was surprised to recently notice a yellow banner on the website of the very
popular Requests library, which urges users to switch to Python 3. That's when
I first thought switching may become inevitable. I guess this is being
orchestrated behind the scenes now.

[https://docs.python-requests.org](https://docs.python-requests.org)

Still, I have no plans to switch. The only useful feature in Python 3 to me is
more liberal use of unpacking. Unfortunately it comes at the cost of removed
tuple parameter unpacking, which I use often, but most users apparently never
do. I don't know what's difficult about Unicode in Python 2 either, once you
understand the difference between Unicode and UTF-8.

It's unfortunate it ever had to come to this. Makes you wonder what Python
would be like today without Py3K. (It's an open question.)

~~~
deathanatos
> _I don 't know what's difficult about Unicode in Python 2 either, once you
> understand the difference between Unicode and UTF-8._

"once you understand the difference between Unicode and UTF-8" is what's
difficult about Unicode in Python 2. I understand it, you might understand it,
but I have to interop w/ and work w/ code written by people who do not. I'm
not fool-proof either, so I greatly appreciate that the language makes a hard
distinction now; doing the right thing _by default_ is the point.

~~~
suzuki
I still use Python 2.7 and all I need with strings is UTF-8 byte string
nowadays in Japan. If you read Japanese, read the following blog to know the
current circumstances:

[https://note.mu/ruiu/n/nc9d93a45c2ec](https://note.mu/ruiu/n/nc9d93a45c2ec)

And note that Golang is getting popular in Japan, which uses UTF-8 byte
strings solely. Python 2.7 with byte strings as default has a good chance to
evolve into a more elegant language :-)

------
pleasecalllater
And the mess in naming functions and classes in the standard library is still
the same. I remember name of a function, and I have no idea how to write it.
As PEP8 says, we have mess in the stdlib, and we are not going to clear it.

Unfortunately they missed the great opportunity which was the release 3.0.

------
ncw33
How dedicated to keep it going so long! Maintenance this long-term is a time-
sucking activity.

------
ridiculous_fish
What is the preferred way to write an end-user program in Python? At least one
platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others
have 2.x as the default (macOS, other Linux distros).

The consequence is that Python scripts which need to "just work" must be
written in the intersection of Python 2 and 3, a language for which _no
interpreters exist_ (do they?), and which inherits the pitfalls of both. This
is a terrible state of affairs.

~~~
joshuamorton
#! /usr/local/bin/python3

Also arch is wrong:
[https://www.python.org/dev/peps/pep-0394/](https://www.python.org/dev/peps/pep-0394/)

~~~
reificator
Sure, if you can make up the rules after someone breaks them, then Arch is
wrong...

From the linked PEP (emphasis mine)

> end users should be aware that python refers to python3 on at least Arch
> Linux _(that change is what prompted the creation of this PEP)_

------
gigatexal
Legacy python needs to be thought of as the plague and avoided. There’s so
much awesome in the 3.5+ land of python. This is a good thing.

~~~
matt_wulfeck
There’s really not anything major in 3 that’s not easily available via back
ports in 2.7. Or else why do you think people aren’t bothering to pay the
price to switch?

This is also the reason maintainers are bringing out sticks. They realize the
carrots just aren’t that tasty.

~~~
shrimpx
Getting rid of the GIL is a big change. In py2.7 CPU-heavy threads are useless
-- they lock up the process and starve other threads. py2.7 threads are only
good for I/O heavy work.

You can use multiprocessing in py2.7 but with a lot of caveats if you want to
share state and file descriptors.

IMO the GIL removal is the one thing "that's not easily available via back
ports in 2.7".

~~~
dec0dedab0de
Python 3 still has the GIL

------
smaili
It would be interesting to see whether Python 2 is the longest supported major
version for a programming language.

~~~
CJefferson
What? No! Python 2 is only 17 years old.

I can still run Java, C, C++ and Perl 5 (picking the first 4 languages that
occur) that were written before then, with no problems.

~~~
jhasse
Most C++ code wont compile for multiple reasons. For example using namespace
std will result in errors if your code calls a function which is now part of
std.

~~~
user5994461
I actually think that migrating from Qt4 to Qt5 has a lot of similarity with
python 2 to python 3. Not sure why there aren't more people doing the
comparison.

~~~
freeone3000
pyqt is a robust enough wrapper to avoid the migration issues, so in a python
thread you won't have anybody who suffered through that mess.

~~~
user5994461
I am not talking about pyqt or python code, I mean pure C++ projects using Qt.
The transition from 4 to 5 had some hiccups.

------
bjt2n3904
I've said it before, I'll say it again. I don't care for everything-is-
unicode-by-default.

You can take my Python 2 when you pry it from my cold dead hands.

~~~
derefr
You know the phrase, "you don't have to go home, but you can't stay here"?

You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you
don't agree with Python 3's stances on things, it might be time to find
another language entirely.

~~~
nas
I think the amount of Python 2 source code existing in the world is too large
for Python 2.7.x to stop working. A lot of that code is just never going to
get ported to Python 3. Companies don't have the budget to do it. So, somehow
there will still be a Python 2 interpreter to run the code, even after 2020.

That said, when nearly all of the Python 3rd-party library developers are
targeting Python 3, do you really want to be stuck on 2.x? I think that's
going to be the ultimate death of new Python 2.x development. The NumPy
example seems typical. I.e. the cost of supporting 2.x is very soon not going
to be worth it.

It seems clear to me now that there is not going to be a large faction of 3rd
party library developers who refuse to move from 2.x. That is unlike Perl 5.
As a Python developer, this is very happy result. The 2 to 3 transition was
extremely painful but it appears to be mostly behind us now. Having two
separate "flavours" of Python (2.x and 3.x) would have been bad.

~~~
acqq
> I think the amount of Python 2 source code existing in the world is too
> large for Python 2.7.x to stop working.

Exactly. And that is the major fu __up that Python 3 brought. There was no
fundamental reason to make most of the Python 2 code incompatible with the
"better" and "newer" version. The really good Python 3 would have accepted
most of the Python 2 code and execute it, while allowing the new 3 "goodies."

Only a year ago, I've installed "just" Python 3 on my main computer -- "Python
3 is mature enough" I've thought. Then I wanted to solve some problem X. Found
the code that does 90% on the web. Try to run -- doesn't work on Python 3.
Adjusting it. It runs after my changes, but I've lost time for something
unnecessary. Then I've tried to solve some problem Y. The story repeats. The
third time, I've just decided that it's not worth. I've installed 2 again and
I can't be happier.

And all that was for my non-Numpy related work. There were some years where
the libraries using Numpy were only Python 2, even after Numpy got its own 3
version.

So Python 3 was so very wrong for too long. The worst upgrade path I've lived
through. And completely unnecessary. It was absolutely technically possible to
make it much much easier to move.

~~~
thanksgiving
Only Python 3? Are we there? I thought we are not there yet? I thought there
is a big push going on for fedora to go Python 3 only and it will likely not
end before end of next year? I imagine Debian and Red Hat and Canonical will
continue python 2 default for a while?

I'd be happy if I'm wrong though...

~~~
acqq
> Only Python 3? Are we there?

In my experience, for my purposes and use cases, obviously not, exactly as I
wrote above. And it didn't have to be that way for most of the code, I claim
that, knowing how little additional code were needed to have a different
result: compare with the Linux Kernel, much more complex piece of code, where
"kernel never breaks user code" because Linus set that goal. Python is much,
much less complex than Linux Kernel, and the same goal was possible: not
breaking at least most of code written for 2, while still allowing different
new code. The overhead would be insignificant. Note that even without that
overhead, Python 3 was (maybe still is) significantly slower than 2. So there
is really no valid excuse.

~~~
thanksgiving
I don't know the details (because I don't understand unicode) but I am not
sure what you said is possible.

But to me ASCII seems like a hindrance.

``` fmt.Println("Hello, 世界") ```

This line of go lang looks beautiful. I bet they never have to worry about
bytes vs Unicode.

Here is python...

[https://www.youtube.com/watch?v=sgHbC6udIqc](https://www.youtube.com/watch?v=sgHbC6udIqc)

I'll add one more assertion to the list. People are born and people die. It is
not fair for us to impose our mistakes and sins to the next generation. With
that being said, my thought was simply all the scripts that are in python
(even the simple build for Firefox was python 2 only last time I checked).

The way forward for anyone new to python is for us to tell them: Python 2
doesn't matter. Don't look at it. Learn python by which I mean 3.0+

I still don't get why Google of all places can't support python 3 in its
standard app engine. To me it sounds like standard is deprecated for the
flexible (which doesn't have a free tier).

------
raker
Good to see that it will be a quiet transition. Linus would approve.

~~~
jwilk
Linus?

~~~
yeukhon
My guess is referring to Linus' philosophy on how software should be developed
and maintained, especially in his own Kernel project. See
[http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html](http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html)

------
julox
its time to use pythonconverter.com !

------
mastax
Better title: Numpy's plan for dropping Python 2.7 support

~~~
sctb
Thanks, we updated the headline to be closer to the original title.

