
Pandas dropping Python 2 support - ptype
https://twitter.com/jakevdp/status/1080583192803823616
======
abakus
Time to move forward. Python 2 is so 2010.

------
amypinka
There was a call asking for volunteers to continue to support 2.7. There's
something like 60K lines of Python code in the project so perhaps coding
standards keeping the 3.x-specific syntax to a minimum means the project can
continue to support a wide installation base without a great deal of overhead
for any would-be 2.7 maintainer.

~~~
orf
Sacrificing the awesome 3.x features (f-strings, typing, metaclasses, object
model improvements) to hold onto a deprecated and soon-to-be obsolete version
of Python seems bad to me.

IMO make a clean cut else it will never end.

~~~
beagle3
Python 1 already had metaclasses (I remebmer it as "the Don Beaudry hack" or
"the Don Beaudry hook", depended on who you asked)

Are Python 3 metaclasses a significant change?

[0]
[https://www.python.org/doc/essays/metaclasses/](https://www.python.org/doc/essays/metaclasses/)

~~~
orf
There are a number of improvements, including how you define them and the
things you can do with them. Some of these tie in with other language
features, e.g typing.NamedTuple[1].

There is also PEP 487[2], which means you can do more without needing a
metaclass.

1\.
[https://docs.python.org/3/library/typing.html#typing.NamedTu...](https://docs.python.org/3/library/typing.html#typing.NamedTuple)

2\.
[https://www.python.org/dev/peps/pep-0487/](https://www.python.org/dev/peps/pep-0487/)

------
beams_of_light
This is painful for Debian users.

~~~
evgen
apt-get install python3

Problem solved.

------
gammateam
Amazing, everyone dropping python2 should have been 2010s headline but hey
whats another decade

~~~
rogerbinns
You didn't hear much from the people using Python 2 to get things done. Here
is what happened in that world:

* there were no syntax changes, no new keywords, no deprecations, no coloured functions ([http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/)), no major changes in the standard library etc

* some sore points (eg subprocess & threads) had backported modules with fixes

* python 2.7 continued to be supported by major third party libraries, and they tended to avoid wholesale changes

* binary compatibility and testing are easy (I have a python binary module compiled on 32 bit ARM in 2014 that still loads without recompilation today)

ie python 2 is more than sufficient to solve real world problems, and in the
__last decade __has been stable, debugged, and predictable. You generally don
't hear from folks doing this!

Much like C++, Python 3 still has the problem of which subset of language
features to use since they affect minimum Python 3.x version, interaction with
libraries etc.

The Python 2 -> 3 transition is going to be a case study for a long time. All
the intentions and planning seemed right, yet here we are a decade later.
There are difficult trade offs between new productivity, stability and
predictability, and giving things time to mature, with space to make mistakes.
As an example Rust seems to be applying the lessons learned.

~~~
t0mbstone
The biggest problem with the python 3 rollout was the decisions that were made
to arbitrarily deprecate functionality that could have easily been supported.

Just because you add a new way to do something doesn't mean you have to get
rid of the old way, too.

Another big mistake that they made was not providing any tooling to
automatically convert python2 to python3 code.

~~~
dragonwriter
> Just because you add a new way to do something doesn't mean you have to get
> rid of the old way, too.

It kind of does if a central part of the stated philosophy of your language is
“There should be one—and preferably only one—obvious way to do it.” [0]

And, sure, you may say backwards compatibility creates a special circumstance
that is an exception, but “Special cases aren’t special enough to break the
rules.” [0]

[0] PEP 20, _The Zen of Python_ ,
[https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)

~~~
eesmith
Just how many ways does Python have to format a string? I can think of at
least four: fmt % args, fmt.format(args), string.Template, and f"fmt".

Just how many ways are there to make a string constant? single and double
quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably
more.

That does feel like sometimes it's okay to support the old way too.

~~~
joshuamorton
>Just how many ways are there to make a string constant? single and double
quotes, 'single quoted' and """triple quoted""", r"aw" and u"nicode". Probably
more.

Those all have different semantics. They aren't the same thing. In python 3,
`''` is a unicode string. `b''` is a byte-string, `''''''` is a multiline
unicode string, and `r''` is a string where backslashes are handled specially
(which is useful for storing regexes and escape sequences in a human readable
way).

Each of those is the obvious way to do the thing. Note that the rule isn't
"one way to do things" but "one obvious way". Its possible to generate a
multiline string by joining a bunch of lines with `\n`, but its more obvious
to use the enter key.

>I can think of at least four: fmt % args, fmt.format(args), string.Template,
and f"fmt".

Indeed, and most would argue that % formatting should be deprecated (and would
have been, if the stdlib logging module didn't rely deeply on it). Format
strings and f strings, are approximately equivalent, but strings.Template
objects serve a different purpose.

~~~
eesmith
What is the obvious way to write a string constant which does not contain a
newline, single quote, or double quote? Should I write it: "this way" or 'this
way'? PEP 8 explicitly says there is no preference.

Sure, they have different semantics. But the Zen of Python suggestion isn't
usually interpreted to accept, say, a 99% overlap in functionality.

~~~
joshuamorton
You didn't mention `''` vs `""`. Those have the exact same semantics. And
indeed there is no preference. The zen isn't a 100% unbreakable set of rules,
its guidelines though, so I'm not sure what you're trying to get out of
catching Python violating a document that contains the lines

> Special cases aren't special enough to break the rules. > Although
> practicality beats purity.

The entire zen is self-contradictory, and people are well aware that python
breaks the "rules" in some places. That doesn't make the guidelines bad, nor
does it make the fact that they guide most of the language and its design less
true.

Having 2 ways of defining string constants is useful. And given that
practicality beats purity and all, its acceptable to violate the Zen when its
sufficiently useful.

~~~
eesmith
My point is that dragonwriter's interpretation of the Zen of Python is not a
strong argument against backwards compatibility support. Your comments support
my argument, but you seem to have misread them as an indictment of how Python
does things.

Here's the thread:

t0mbstone: shouldn't "arbitrarily deprecate functionality that could have
easily been supported"

dragonwriter: They should be because of the Zen of Python.

eesmith (me): but Python _does_ support old functionality, so don't place much
weight in how to interpret the Zen of Python as it applies to (C)Python
development.

I did not say exactly that because I thought the inference was easy to make
given the g'parent threads.

~~~
joshuamorton
Ah, but here's the disagreement:

> but Python does support old functionality

is completely compatible with "should deprecate functionality that could have
easily been supported". There should be only one way to do it is correct.
Under the zen, you should bias towards deprecation. That doesn't mean
deprecate every old functionality always. Indeed if there are compelling
reasons not to deprecate something (the maintenance cost truly is zero, it is
infeasible, the new functionality only covers a subset of uses, etc.) you
shouldn't!

The python mailing list and peps have a good bit of discussion about most
backwards incompatible changes from py2 -> 3 (and more recent ones, like
adding new keywords).

~~~
eesmith
Yes, and I pointed out one of the reasons for not supporting backwards
compatibility in
[https://news.ycombinator.com/item?id=18819491](https://news.ycombinator.com/item?id=18819491)
. There are many others of course.

It's in a parallel thread because it's a response to t0mbstone's statement
that Python developers should have done more work to support backwards
compatibility.

I am not saying that Python should "deprecate every old functionality always",
but that is what dragonwriter seems to be arguing.

dragonwriter made a different argument about why to drop backwards
compatibility, based on an interpretation of the Zen of Python. My response on
this thread is to say that that interpretation of the Zen of Python is not
valid, or at least weak, given that it does not explain Python's own
development history.

Something that I am sure that you agree with.

I don't see where your views disagree with mine.

