Pandas dropping Python 2 support
twitter.com
twitter.com
IMO make a clean cut else it will never end.
Are Python 3 metaclasses a significant change?
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...
Python 2 dinosaurs will need to come to with a Babel-style project to transliterate modern syntax —3to2, if you will— and rebase their code from that. It's going to be hell to maintain.
Problem solved.
Which is unfortunate. But hey, all good things come to those who wait. And wait. And wait.
I can't think of any open Python project with that size, and I can't imagine an organization maintaining one. And I can easily agree that such project won't migrate from Python 2 to 3 in a year. It won't migrate in a decade either, or in a century.
Large Python projects are possible, but if you don't have good discipline and organization, it can quickly become a mess (probably true regardless of the language).
I'm not sure how much effort it'd be to migrate all of that to Python 3, but I'm sure it's not trivial. But, I also don't think it'd be a multi year effort. It also wasn't a big monolithic project, so a migration could be done piecemeal.
Python 3.7 has 542,292 lines of Python, according to David A. Wheeler's 'SLOCCount' . And another 418,581 lines of C.
NumPy has 159,208 lines of C and 113,842 of Python.
SciPy has 174,580 lines of Python, 83,155 of C, and 79,514 of Fortran.
Pandas has 225,417 lines of Python.
Put them all together and that's 1M lines of Python to run the standard Python data stack.
Here are all the milestones https://python3statement.org/
Here's a blog post about Dropbox migrating from python 2 to 3 https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...
* there were no syntax changes, no new keywords, no deprecations, no coloured functions (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...), 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.
I'm confused, are you trying to say a module compiled for Python 2.7 still works with Python 2.7?
By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7.
Of course it does. Just like every other version? Compile something for Python X and it will continue working for Python X, where X is 2.7, 3.1, 3.4, etc etc.
Overall your point seems to be very confused: Modules compiled for a Python version that has had no updates in 15 years still work, and this is somehow relevant to modules working across Python releases? You're comparing apples to oranges here I feel.
> By contrast if you compile a module against Python 3.4, it won't even work the same day against Python 3.5. ie the ever changing Python 3.x is more busy work than Python 2.7.
Sure, that's a different thing. That's across Python versions. As a counterpoint, Tensorflow built for Python 3.6 before 3.7 even began development runs just fine on 3.7.
Of course the C-API evolves, and you'll have to adapt your C-API modules. As an example 3.6 made some changes[1].
1. https://docs.python.org/3/whatsnew/3.6.html#build-and-c-api-...
This isnt really about rationalizing Python2
Its about different branches of a programming language bearing sequential names
Thats the only real UX problem here
Naming candidates: Python++, Python Vision, Python Classic/Python, Python Core
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.
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/
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.
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.
Sure, they have different semantics. But the Zen of Python suggestion isn't usually interpreted to accept, say, a 99% overlap in functionality.
> 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.
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.
> 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).
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.
While true in the abstract, who will do that support? Python core developers are stretched enough as it is. Why should they volunteer for that?
"not providing any tooling to automatically convert python2 to python3 code"
They did - https://docs.python.org/2/library/2to3.html ("2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code"). In practice that turned out to not be approach that most people wanted to do, but you can't say they provided no tooling.