Also worth remembering that Linux distributions with long term support like Debian, Ubuntu and RHEL will continue to support and patch Python 2 as needed for a number of years.
That’s one reason I advocate for plain English in business (esp support/docs/training) and government (esp anything mandatory). It also helps the illiterate and people with bad memory that forget uncommon words.
often talk too fast for others to follow, and use jokes, slang and references specific to their own culture
This can even be a problem among English speaker. I was meeting this fella from NYC a few weeks ago via couchsurfing, and told him via WhatsApp that I’d join him for the craic after getting back from the chipper. He had no idea what I was on about. English is tricky because there are so many variants, and once you get in to the habit of using a regional variant of it, it’s hard to get rid of that.
Applicable: Native English speakers are the world’s worst communicators
More accurate title: “Native English speakers are worse at communicating with ESL folk than ESL folk are at communicating with other ESL folk, in English.”
Like c’mon it’s not like English is the only language with slang
What language would you expect? It’s specifically meant for all users, including those that “just use” Python 2.
I think it is very clear (except the word “sunsetting”, which is worst of US marketing speak and is not understandable to many second language speakers).
I bet there are a lot. The “tech industry” is lead by people following closely the upstream projects, but a long long tail of activities just getting stuff done imitating the others follow, and changing that will be long.
There are also many code bases in production to convert. There is a tendency to not daring to touch to anything in production if it works, even though maintenance is required.
A lot of people don’t have the necessary attention span time to be able to read long blog posts, announcements or messages. They refer to such messages as “it doesn’t tell about anything”, “meaningless” and “they don’t want to waste time”. I think by using simplest language possible, they’re trying to embrace the short-attention-span people so that they’ll be able to actually read and “digest” the message.
I’ve used “they”, but I know I’m not separated from this issue myself. Many times when I’m stumbling over some article in English, I’m discouraged by the overly flowery language, which I often can’t easily understand (as I’m not a native speaker). So I perfectly understand why the Python note uses Simple English mode :)
It’s not you, I had the same reaction. From the tone of the article my impression was that their target audience is four years old.
I get that shrouding a simple message in complicated verbiage is a great way to alienate readers but going to far in the opposite direction makes it sound condescending which is possibly worse.
But in this case I’m sure that was not the intent of the author, my assumption is that English is not the writer’s first language and they were trying to be very sure they didn’t make anything unclear or misleading. Sometimes my own writing turns into this after I’ve rewritten it 20 times.
To quote my mentor at Amazon: “Communication is impossible”.
Have you ever watched a really painful exchange between a non native English speaker and well meaning but frustrated people on a chat channel trying to help?
The non native English speaker asks a question in the best way they can, using imprecise wording and breaking every rule in the English language because, to non speakers, they make no sense :)
So yeah, this announcement is written in a way that optimizes for minimizing mis-understanding, and in this context I see that as the right choice, and if I’m reading you right, so do you :)
I’m guessing it’s because they wrote sentences starting with And and But a fair bit, which is potentially easy to read but makes all of the sentences seem really short. It’s a little strange, but much better than paragraph-length sentences.
I am disappointed in the Python Software Foundation for once again leaving PyPy out in the cold. It has been a pattern for over a decade that CPython’s developers shortsightedly ignore alternative Python implementations, and now they have taken the extraordinary step of forcefully deprecating the dialect of Python used by the PyPy team.
I’ve reached out to the Python Software Foundation repeatedly through official and semi-official channels, but never gotten a good clarification on the matter. PSF’s continued endorsement of a pile of C over a pile of Python is hypocritical, and now their attempt to control an ecosystem that is beyond them is ignorant; this ridiculous situation should not ever have happened, but continues to happen because of poor communication.
[…] in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020
(my emphasis)
So the PyPy team has had between 12 and 5 years to move to Python 3, depending on how seriously they took the deprecation message. Or am I missing some internal Python wrangling here?
Yeah, there’s two things you’re missing. First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap. These days, PyPy is capable of providing that bootstrap interpreter itself. Rewriting RPython would require a massive engineering effort, and there is not funding for such a venture. The latest position of the PyPy/RPython team is in a 2016 blog post:
PyPy’s own position is that PyPy will support Python 2.7 forever—the RPython language in which PyPy is written is a subset of 2.7, and we have no plan to upgrade that.
Second, it is well-known community folklore that GvR doesn’t really like PyPy or Jython or any other alternative to the reference interpreter. He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:
An endorsement of PyPy as an alternative to porting to Python 3 will not be coming from the PSF – we wish PyPy the best of luck with their own Python 3 transition, but we don’t think they are a good alternative to dropping Python 2 support.
They would like to exterminate Python 2, and by extension, snuff out any ecosystems which aren’t porting forward to the latest and greatest PEPs offered by the CPython 3.x branches.
Python 3 already was a hard fork of Python 2. The two languages are clearly distinct; they are mutually incompatible in syntax and semantics. Why must the Python 3 folks now destroy the last of Python 2?
That’s quite the opposite of what’s actually happening; they are saying that they want alternative Python 2 implementations, which are still going strong and aren’t dying anytime soon, to also go away. I do blame them, yes.
Speaking as someone who maintains Python packages, I understand their position.
If the message were “one of many Python 2 interpreters is going to be unmaintained, but that’s no big deal and you can still get a maintained one to keep running all your Python 2 code”, well, that would mean people coming to me, and other package maintainers, and asking to have third-party packages maintained with Python 2 compatibility for as long as there’s a supported interpreter.
And I have no interest in that. Some aspects of 2/3 compatibility are not that hard, sure, but others can be a bit complex. And I’d be permanently held back from using most new features of modern Python, because those features aren’t going to be backported into a supported Python 2 interpreter (as I understand it, PyPy would never have interest in this; their desire is for Python 2.7 to remain supported but feature-frozen).
If PyPy wants to internally maintain the interpreter they use to bootstrap, I don’t care one way or another. But if PyPy wants that to also turn into broad advertisement of a supported Python 2 interpreter for general use, I hope they’d consider the effect it will have on other people.
Sure. As somebody who maintains Python 2 codebases, I have felt the constricting effects of more and more packages no longer offering Python 2 versions, forcing folks to commit to increasingly-outdated vendored code.
PyPy has broadly advertised a general-purpose Python interpreter for sixteen years. An example release announcement from last year advertises “almost a drop-in replacement for CPython”. It’s fun to watch the effect that this already existing system has on folks; this entire thread has been folks having effects because of PyPy. PyPy exists, and that disrupts the picture of the ecosystem painted by PSF.
There are a few things here that your comments have equivocated, and that equivocation leads to difficulty.
The CPython interpreters, for various versions of the Python programming language
The end-user deliverable interpreters of the PyPy project, for various versions of the Python programming language
The interpreter used by the PyPy project to bootstrap RPython
The abstract concept of the Python programming language, as embodied in a prose specification
Items 1 and 4 are copyrighted by the Python Software Foundation, which also owns the trademark for the Python programming language. Items 2 and 3 are under the control of the holders of PyPy’s copyright (a long list of individuals and other entities).
PyPy could, if the project chose, sunset its end-user-deliverable Python 2 interpreter on 2020-01-01, refuse to accept bugs from end users who wish to continue running software that is compatible only with Python 2, and maintain a Python 2 interpreter solely for the purpose of bootstrapping RPython.
Or, PyPy can publicly maintain an interpreter for Python 2 past 2020-01-01, including accepting bug reports from end users who wish to continue running software that is compatible only with Python 2.
You seem to strongly prefer the latter option. The only way in which your stated list of enemies (Guido, the CPython core team, the PSF) could interfere with that is by asking that the interpreter not be named “Python” (since the PSF owns the trademark). But the interpreter is already not named “Python”, so that’s moot.
But by doing so, PyPy would introduce a maintenance burden, or at least pressure to take on a maintenance burden, for other projects which wish to drop Python 2 and make use of new features only available in Python 3, since PyPy’s continued offering and support of an end-user-deliverable Python 2 interpreter would extend the life of software that is only compatible with Python 2.
This is the point I was making above, as a way of reminding you that while you’re complaining about the impact of the CPython/PSF messaging on you, you’re neglecting the impact of your messaging on others.
Also, I do wonder whether PyPy is really prepared to take on the burden of maintaining a high-profile Python 2 interpreter over potentially very long time scales, given the resource constraints which already have prevented being able to move it to bootstrap from Python 3.
Finally:
I have felt the constricting effects of more and more packages no longer offering Python 2 versions, forcing folks to commit to increasingly-outdated vendored code.
The alternative is to force the maintainers to continue supporting software they don’t want to support. For my own projects, I’m supporting Python 2 until 2020-01-01, and then I’m done and will enjoy getting to finally start using features of Python 3. While I have some sympathy for people who are still immovably on Python 2, I don’t feel any obligation, nearly 12 years after Python 3 was released, to continue maintaining things for them for free.
They will wave their totalitarian hand over the open source and free software they have released with the right for anyone to do with as they please and say “magically, we will destroy your ability to yourself do as you please with this software we don’t want anymore” and then we will all weep our crocodile tears as open source python has been cancelled.
What do you propose they do then? Extend Python 2 support forever and let Python 2 slow down Python 3 development for all time?
What do you suggest they do about the real problem that it’s confusing for new programmers and users, and annoying for experienced programmers and users, that there are two Python dialects? Should Python programmers just forever have to decide between limiting themselves to writing code compatible with both Python 2 and Python 3, or writing code which a lot of users can’t run?
I get the feeling that you think they should’ve just made backwards-compatible improvements to Python 2 rather than breaking it with a major release of the language, and maybe that would’ve been better, but that’s not what they did. Therefore, I’m curious about what you would want them to do given the current situation, not what they should have done a decade ago.
What they should do now, given the current situation, is admit that PyPy is a reasonable implementation of Python 2, and admit that CPython’s demise does not doom the rest of the Python 2 ecosystem.
New Python programmers already must contend with the fact that the PSF publishes two manuals, one for Python 2 and one for Python 3, which look extremely similar, overlap greatly, and come up simultaneously in search results.
“First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap.”
That’s them choosing and forever staying on a specific dependency. We generally don’t force suppliers to support anyone doing that unless they’re customers paying for backward compatibility. Even then suppliers might not find it worth their time and effort.
Let’s say we address the dependency. Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python? That versus the effort to maintain and polish Python itself for just that dependency?
Seems more fair for the project that wants the dependency to be the one reworking it. Also fairer division of labor given other option is an externality.
“Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.
Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python?
Yes. Additionally, you clearly don’t know either dialect of Python, and you clearly have not done such a port. I encourage you to do so! You will learn a lot. You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. For RPython, I would say that it is infeasible and not worth attempting unless somebody is paying.
““Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.”
Your original claim was about the Python Foundation, which you said backed CPython, was sunsetting support for Python 2 after telling everyone they’d do it for a long time. They were putting all their effort into Python 3. You then said this was a problem since another team, PyPy team, had a dependency on Python 2, had no intention to change that due to one component, did their own implementation of Python 2, and would stay on it.
That means this is an externality for PyPy, costing Python Foundation, where some other group is expected to support a language and its associated ecosystem just because of their dependency choices and porting preferences. I don’t see anything wrong with the other group saying, “No, we and our foundation have moved on in what we think are better directions. Anyone wanting to support the legacy tech can feel free. It’s on them since it’s not benefiting us.” Just going by what facts you’ve given here.
“you clearly don’t know either dialect of Python”
I used one here and there a long time ago. Don’t know either currently. I’ve been reading about Python 2 maybe getting ditched for Python 3 in these forums for a long time. So, I started asking some questions.
“You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. “
Likewise, supporting an entire language, its libraries, security fixes, etc so some other people don’t have to port code is probably manual, less trivial than one component, and will drag on for years to decades. I’ve seen lots of companies port Python to Go. A Python to different kind of Python port of one component by Python experts is probably easier than maintaining a whole implementation of Python and its libraries. Just a guess.
If PSF is doing it for PSF, then by all means maybe they should maintain a whole platform. It’s different if it’s a lot of work, an externality for someone else, and they refuse to do a smaller set of work on their end. Again, just going by what you’ve described. If the facts are different, then this analysis would be wrong.
You are equating the support from PSF of Python 2 with the existence of any Python 2 interpreter. If, tomorrow, all CPython 2.x installations stopped working, PyPy users would nonetheless still be able to execute pip or another pure-Python package manager and download Python 2 packages from PSF-operated infrastructure. This is an example of the sort of non-CPython-specific support for the entire Python community under PSF’s control.
The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.
Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence. Many folks simply wanted Python 2 to become Python 3, a fantasy paid for with developer-hours.
“The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.”
That’s on them is my point. If they want PSF support, they need to give them a reason that works to their liking. If not, ignore them with a marketing strategy and/or foundation of their own that supports their goals. That’s how these things work.
“Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence.”
Sure. If corporations and GvR are in control, then CPython development needs to continue to reflect what they want out of pragmatism or expect lots of failure. Anyone not liking the decisions of those corporations and GvR should fork Python totally to support their vision with their own resources with no hate or aggravation toward the others acting in their own self interests. Maybe even out-compete them with their own language extensions and/or higher-performance implementations [1] on top of better marketing strategy and funding outreach. The kinds of things developers and organizers did for older versions of Python to get them where they were.
Edit: [1] Adding that Nim and Julia are sort of doing that already even though I meant an improved version of Python. Nim has Python-like syntax with extra features and higher-performance during runtime. Its getting some Python users. Python is entrenched in scientific computing. Julia is grabbing some of those people with alternative design, focus on higher performance, and focus on easier integration with C libraries while still keeping Python ones. They’re both getting users with Julia getting a lot of them.
This isn’t about PSF support, although if we’re going to talk about PSF support, it’s notable that the total sum investment of the PSF in PyPy is $10,000. I can guess at the salaries of the typical CPython core developer, and they’re a little better than five figures. It was only a year or two ago that PSF even opened up their grant program to allowing PyPy, Jython, or other non-CPython-based projects to apply for grant money.
This is about the words at the top of the original post. To remind:
We are volunteers who make and take care of the Python programming language. We have decided that January 1, 2020, will be the day that we sunset Python 2.
These words purport to speak for PyPy’s team and any other Python 2 team. These words claim that Python 2 will be removed from our hands next year. Can you grok this? Do you understand why it might be a bit of a problem that the group that sits on the pile of money and trademarks has unilaterally decided that entire branches of the family tree must be pruned?
Not Nim, but indeed Julia, as well as my own Monte, Hy, Quill, Lever, and likely others, all came from the realization over half a decade ago that the PSF was disowning Python 2 and would only acknowledge Python 3 as the one true Python. If we’re not going to keep the name, why keep the semantics? We could improve.
These words purport to speak for PyPy’s team and any other Python 2 team
The original post was published on python.org, which has an SSL cert published by the Python Software Foundation. It’s published by the PSF and speaks for them.
You are making weird semantic shifts between “Python the language”, “Python the implementation”, and “Python the trademark” all over the place.
It’s clear you (and maybe the rest of PyPy) have no love for Guido van Rossum, and maybe not the PSF. But the fact is that they own the trademark to Python. Trademarks exist in part to prevent customers from confusing one product for another. That way, no-one will be confused when the code they get from the PSF (Python 3) won’t run on PyPy (Python 2).
That said, I’m sure no-one would object to say a product called “PyPy - a version of the Python language and runtime based on Python version 2.7”.
From what I’ve read in this thread, it seems that PyPy wants to have their cake and eat it - they want full and continued support from the PSF for Python 2, while at the same time being entirely separate from them and not have to follow the PSF in any other matter. I really don’t see why the PSF has to go along with this arrangement.
Second, it is well-known community folklore that GvR doesn’t really like PyPy or Jython or any other alternative to the reference interpreter. He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:
This is a sticky wicket, and it’s by no means unique to Python. Witness the difficulty non standard Ruby, Perl etc. implementations have had keeping up with the reference implementation.
In the end, a most language communities end up, as Guido/Python did, deciding to focus on one implementation and say “This is THE reference implementation of the language”.
Doing anything else requires a massive outlay of man hours that just don’t exist in communities like Python - you’d need something like the Jave TCK.
He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:
This is not a fair reading of what Guido actually said in that issue. He is talking about PyPy being an alternative to Python 2, and being disappointed they’re not implementing Python 3. He didn’t mention anything about Python being “unified under a single holistic banner” or PyPy being a “threat”
It’s totally understandable that you dislike my opinion. This is a synthetic opinion of GvR’s desires that comes not just from this post, but from years of interactions with him, including a particularly memorable dinner from a PyCon in Montreal a few years ago.
PyPy is not just an alternative to Python 2; there is a Python 3 branch. Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy. I can’t imagine that his disappointment is that PyPy doesn’t have Python 3 support, but more likely that PyPy exists at all and mars the otherwise-singular transition between languages.
PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers. We sometimes like to imagine a world where Python interpreters were fast, but this is apparently not that world.
Can you cite conversations online where CPython core developers are displaying this sentiment?
For me, peak-PyPy and excitement around alternative implementations happened in the 2008-2012 window. What I mean by this, is that everyone was excited about alternative implementations driving performance forward at a time when folks weren’t so worried about Python 3 compatibility, and Python itself was just getting into a growth curve. I’d cite Dave Beazley’s PyCon Keynote at PyCon 2012 as an example of how PyPy wasn’t sidelined to the degree you argue it is.
Fast forward a few years and folks are in the trough of disillusionment, to steal a phrase from tech analysts. There were lots of (invalid, but) broken expectations in the community. Unladen Swallow, Jython, IronPython, and PyPy (to name just a few) hadn’t taken the world by storm and we were still trying to remove the GIL without breaking C extension compatibility. There were a lot of good intentions about getting and staying compatible with the Python mainstream - but this didn’t happen, and the alternative implementations got behind. PyPy’s history of Python 3 funding has some relevant detail.
It’s great that PyPy has caught up, but there is some way to go as far as being a strategic choice for folks. Even with CPython’s pretty obvious deficiencies it’s been able to carry a community forward to a place that’s very different from 2008. PyPy can make the argument that it’s a viable and supported Python 2 that could even get better, but very few people want this, even if they have to support Python 2. Python developers for the most part want to move to Python 3 because it’s finally a compelling option. In my mind, it’d be better if PyPy adapted to the current environment and attempted to overtake CPython as the platform of choice for Python 3 instead of fighting old battles for a diminishing platform.
Sure, you’re part of one arm of the massive galaxy of Python. However, you should know that there is another arm, where:
C extensions are shunned; speed comes from PyPy
Conda? Ha, no, we use real package managers, like Nix
asyncore? asyncio? No, we use Twisted
There is a clear difference between Unladen, Pyjion, Pyston, etc. vs PyPy: PyPy is a true community project, not a corporate timewaster. If that makes it less strategic, so be it; the clear difference is that PyPy ships, and has been shipping for years. In 2008, it was already shipping, already fast, and the PyPy position was that CPython folks should keep CPython as the reference interpreter, but encourage PyPy and Jython experimentation, deprecate the C API, and encourage platform-neutral portable Python. This position of ours is over a decade old.
“Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy.”
They’ve done a lot of work. They deserve more visibility. I’ve always mentioned them to people interested in Python implementations.
“PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers.”
The desires of a project’s developers rarely determine what massive amounts of people in the real world do. Especially across many disciplines that we see Python in. That’s marketing, what default binaries are available in package managers, what people in charge prefer, what gets the most press, word of mouth pushing each person’s favored version, etc. These things drive language adoption on large scales.
The core Python team has a good brand and product they got bundled in most Linux distro’s by default with almost anything people read about Python pointing them in that direction. That’s why most use something like that vs PyPy. The PyPy team would have to step up big time on all the non-technical things that help achieve market success. Especially working with major distro’s to bundle them instead of reference Python. I don’t know what they’ve done on any of that since I just occasionally looked at the project being impressed at the technical work they put in.
I need to quote a PyPy developer. They contribute quite a bit of code, but crucially rely on funding, either from community awards or from paid consulting, to make their living. Their reaction upon reading GvR’s words earlier:
it seems like they’re trying to actively hide the fact that there is and will be a supported python 2 version
As for distro involvement, all of the big distros (Debian, Fedora, Gentoo, OpenSUSE) have a PyPy package of some sort. It’s second-class in many distros, because the core packages of the system are written specifically for CPython.
Many many PyCon hallway discussions have been expended over this. I know that, as an outsider, it seems like this is a matter of marketing or some other intangible/bullshit matter of business, but inside the Python ecosystem, there has grown to be a vast divide between those of us focused on speed in Python and speed beside Python. We former have always been willing to accept being second-class to some extent, but here we are asked to abide a terrible distortion of reality where Python 2 and Python 3 are equivocated in order to fulfill the prophecy and consolidate power over both languages.
I am enjoying your explanations, and lament your suffering, and if I had a clue, I might also have an opinion. But I just want to point out that I think when you grabbed the word “equivocated,” you were really reaching for “equated.” The way you have it reads as tho both the languages are being “made into mistakes.”
If you meant it in the sense of “hide the truth,” then that should be something being done by people. “To equivocate” cannot take a direct object. CPython partisans may equivocate about Python versions, but the versions may not be equivocated by somebody (only truth in general can “be equivocated,” and to so state is tautological to the point of ungrammaticality) nor may they themselves equivocate (unless it’s anthropomorphism, which makes sense, e.g. Python 2 equivocates about strings being Unicode or bytes).
Thanks for taking the time to reply. I can see from the language you’re using is that this is not just a technical matter, there are deep personal disagreements at play on both sides which makes this transition so hard.
I just have two followup questions related to the future of PyPy
would not the the new features of Python 3 make it easier to implement an alternative Python runtime to compete with CPython?
if not, it sounds as if the PyPy project is the perfect team to take over maintenance of Python 2, effectively forking the language and leaving a path forward for those to do not want to update to Python 3. The lack of funding would be alleviated by the support of those people or organizations who wish to continue to use Python 2.
To your first question: No; see for yourself. Some features are neutral, some features are harmful. When it comes to RPython, the language is already restricted compared to Python 2, because the whole program is subject to type inference. Python 3 doesn’t offer any features which support type inference. (Annotations don’t help type inference more than actual code!) Some features, like ordered dictionaries by default, were first developed in PyPy and then copied by CPython later.
There is exactly one feature worth borrowing from Python 3, f-strings, but don’t bother. Python 3 gained them around the same time that ECMAScript gained template literals. Of course, in the original languages Scheme and E where the technique was pioneered, these templating strings can be used not just as builders of values, but also as patterns which destruct values. And in E, it is possible to customize how the value is built, by writing a custom builder. However, in Python 3, f-strings cannot be used as patterns, nor can custom builders be used. I asked somebody involved in drafting that PEP why the feature wasn’t lifted in toto, and they replied that nobody else in the room of CPython core developers had understood why it would be useful.
To your second bullet point, yes, there is a possible world where PyPy jumps from less than 5% usage this year to over 50% next year for Python 2. I don’t know whether that world is going to happen, because I believe that the PSF will put in effort to prevent Python 2 ecosystems from flourishing without their permission.
But funnily enough I expect that we’re likely to see tools to analyze codebases for safety to port to PyPy for this reason; and one-and-done solutions for adapting c-based packages to work with PyPy.
That or blog posts from the interested parties explaining why that’s so infeasible that they’re finding CPython 2.7 security.
PyPy is a compliant implementation of Python. There are documented differences from CPython, but in general, you should be able to write pure Python and have it work with PyPy.
The main barrier to PyPy adoption is the continued existence of CPython’s C API.
More or less all scientific and data science users of python use libraries that depend on the CPython C API.
For them, PyPy is not a useful alternative.
Besides that, as they say in the announcement, many open source projects will stop supporting python 2. They’ll do that because it is work to support python 2 and they prefer to use or be compatible with 3.
PyPy has reasonable support for python 3 and the py2.7 required for bootstrapping can be maintained or replaced - it’s not like it needs any bug or security fixes for this purpose.
Right. Which is why you’d want to analyse your codebase for both use of c-based libraries and the weird dumb things you would do hit those documented differences.
The fact that print ‘foo’ no longer works in python 3 is the most annoying change. There’s no reason for it, and almost 100% of my code would run fine on python 3 if not for it.
Python is so lucky they won the mindshare war. This upgrade has been a mess.
Speaking as someone who is going through a long delayed upgrade from 2 to 3 at the moment, if print becoming a function is the biggest issue you will have, you would have no problem just running 2to3 and being done with it.
But print is probably not the issue. For us, it’s been the distinction between bytes and string (or, that our codebase relied on the lack of distinction in python 2).
The only thing I can think of now whenever the 2-to-3 debacle comes up is this: https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/
Also worth remembering that Linux distributions with long term support like Debian, Ubuntu and RHEL will continue to support and patch Python 2 as needed for a number of years.
True, it’s part of the current stable release of Debian. However, Python 2 is going away in Debian’s next release, “bullseye”.
Does anyone else think this announcement is written using unusually simple English prose? It has a sort of Simple English Wikipedia vibe to it.
Python has a massive user base, many for whom English is not their first language. Making this as clear and unambiguous as possible is good.
That’s one reason I advocate for plain English in business (esp support/docs/training) and government (esp anything mandatory). It also helps the illiterate and people with bad memory that forget uncommon words.
Applicable: Native English speakers are the world’s worst communicators
This can even be a problem among English speaker. I was meeting this fella from NYC a few weeks ago via couchsurfing, and told him via WhatsApp that I’d join him for the craic after getting back from the chipper. He had no idea what I was on about. English is tricky because there are so many variants, and once you get in to the habit of using a regional variant of it, it’s hard to get rid of that.
More accurate title: “Native English speakers are worse at communicating with ESL folk than ESL folk are at communicating with other ESL folk, in English.”
Like c’mon it’s not like English is the only language with slang
Did he ask if there was chance for a shift? (… in your diction?)
What language would you expect? It’s specifically meant for all users, including those that “just use” Python 2.
I think it is very clear (except the word “sunsetting”, which is worst of US marketing speak and is not understandable to many second language speakers).
I believe you meant to write “sunsetting”. I do agree that “subsetting” is hard to understand 😉
Correct. lobste.rs is pretty usable on mobile, but that also makes it vulnerable to autocorrect :D.
They’re trying to communicate with people who are still using Python 2 in 2019.
I bet there are a lot. The “tech industry” is lead by people following closely the upstream projects, but a long long tail of activities just getting stuff done imitating the others follow, and changing that will be long.
There are also many code bases in production to convert. There is a tendency to not daring to touch to anything in production if it works, even though maintenance is required.
A lot of people don’t have the necessary attention span time to be able to read long blog posts, announcements or messages. They refer to such messages as “it doesn’t tell about anything”, “meaningless” and “they don’t want to waste time”. I think by using simplest language possible, they’re trying to embrace the short-attention-span people so that they’ll be able to actually read and “digest” the message.
I’ve used “they”, but I know I’m not separated from this issue myself. Many times when I’m stumbling over some article in English, I’m discouraged by the overly flowery language, which I often can’t easily understand (as I’m not a native speaker). So I perfectly understand why the Python note uses Simple English mode :)
It’s not you, I had the same reaction. From the tone of the article my impression was that their target audience is four years old. I get that shrouding a simple message in complicated verbiage is a great way to alienate readers but going to far in the opposite direction makes it sound condescending which is possibly worse. But in this case I’m sure that was not the intent of the author, my assumption is that English is not the writer’s first language and they were trying to be very sure they didn’t make anything unclear or misleading. Sometimes my own writing turns into this after I’ve rewritten it 20 times.
To quote my mentor at Amazon: “Communication is impossible”.
Have you ever watched a really painful exchange between a non native English speaker and well meaning but frustrated people on a chat channel trying to help?
The non native English speaker asks a question in the best way they can, using imprecise wording and breaking every rule in the English language because, to non speakers, they make no sense :)
So yeah, this announcement is written in a way that optimizes for minimizing mis-understanding, and in this context I see that as the right choice, and if I’m reading you right, so do you :)
I’m guessing it’s because they wrote sentences starting with And and But a fair bit, which is potentially easy to read but makes all of the sentences seem really short. It’s a little strange, but much better than paragraph-length sentences.
Mercurial is the only thing I use that depends on Python 2. I guess git would be the only way to go then.
Python 3 support is in Beta, though.
https://www.mercurial-scm.org/wiki/Python3
I am disappointed in the Python Software Foundation for once again leaving PyPy out in the cold. It has been a pattern for over a decade that CPython’s developers shortsightedly ignore alternative Python implementations, and now they have taken the extraordinary step of forcefully deprecating the dialect of Python used by the PyPy team.
I’ve reached out to the Python Software Foundation repeatedly through official and semi-official channels, but never gotten a good clarification on the matter. PSF’s continued endorsement of a pile of C over a pile of Python is hypocritical, and now their attempt to control an ecosystem that is beyond them is ignorant; this ridiculous situation should not ever have happened, but continues to happen because of poor communication.
From the linked post
(my emphasis)
So the PyPy team has had between 12 and 5 years to move to Python 3, depending on how seriously they took the deprecation message. Or am I missing some internal Python wrangling here?
Yeah, there’s two things you’re missing. First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap. These days, PyPy is capable of providing that bootstrap interpreter itself. Rewriting RPython would require a massive engineering effort, and there is not funding for such a venture. The latest position of the PyPy/RPython team is in a 2016 blog post:
Second, it is well-known community folklore that GvR doesn’t really like PyPy or Jython or any other alternative to the reference interpreter. He would like for Python to be unified under a single holistic banner, and alternative interpreters present a threat. I was able to recently get him to clarify his position on the GitHub issue for the linked post:
They would like to exterminate Python 2, and by extension, snuff out any ecosystems which aren’t porting forward to the latest and greatest PEPs offered by the CPython 3.x branches.
Sounds like you want a hard fork. Why not do that?
Python 3 already was a hard fork of Python 2. The two languages are clearly distinct; they are mutually incompatible in syntax and semantics. Why must the Python 3 folks now destroy the last of Python 2?
They do not “destroy the last of Python 2”, they are just saying that they have no will in maintaining it any longer. Would you blame them?
That’s quite the opposite of what’s actually happening; they are saying that they want alternative Python 2 implementations, which are still going strong and aren’t dying anytime soon, to also go away. I do blame them, yes.
Speaking as someone who maintains Python packages, I understand their position.
If the message were “one of many Python 2 interpreters is going to be unmaintained, but that’s no big deal and you can still get a maintained one to keep running all your Python 2 code”, well, that would mean people coming to me, and other package maintainers, and asking to have third-party packages maintained with Python 2 compatibility for as long as there’s a supported interpreter.
And I have no interest in that. Some aspects of 2/3 compatibility are not that hard, sure, but others can be a bit complex. And I’d be permanently held back from using most new features of modern Python, because those features aren’t going to be backported into a supported Python 2 interpreter (as I understand it, PyPy would never have interest in this; their desire is for Python 2.7 to remain supported but feature-frozen).
If PyPy wants to internally maintain the interpreter they use to bootstrap, I don’t care one way or another. But if PyPy wants that to also turn into broad advertisement of a supported Python 2 interpreter for general use, I hope they’d consider the effect it will have on other people.
Sure. As somebody who maintains Python 2 codebases, I have felt the constricting effects of more and more packages no longer offering Python 2 versions, forcing folks to commit to increasingly-outdated vendored code.
PyPy has broadly advertised a general-purpose Python interpreter for sixteen years. An example release announcement from last year advertises “almost a drop-in replacement for CPython”. It’s fun to watch the effect that this already existing system has on folks; this entire thread has been folks having effects because of PyPy. PyPy exists, and that disrupts the picture of the ecosystem painted by PSF.
I’m aware of PyPy’s existence.
There are a few things here that your comments have equivocated, and that equivocation leads to difficulty.
Items 1 and 4 are copyrighted by the Python Software Foundation, which also owns the trademark for the Python programming language. Items 2 and 3 are under the control of the holders of PyPy’s copyright (a long list of individuals and other entities).
PyPy could, if the project chose, sunset its end-user-deliverable Python 2 interpreter on 2020-01-01, refuse to accept bugs from end users who wish to continue running software that is compatible only with Python 2, and maintain a Python 2 interpreter solely for the purpose of bootstrapping RPython.
Or, PyPy can publicly maintain an interpreter for Python 2 past 2020-01-01, including accepting bug reports from end users who wish to continue running software that is compatible only with Python 2.
You seem to strongly prefer the latter option. The only way in which your stated list of enemies (Guido, the CPython core team, the PSF) could interfere with that is by asking that the interpreter not be named “Python” (since the PSF owns the trademark). But the interpreter is already not named “Python”, so that’s moot.
But by doing so, PyPy would introduce a maintenance burden, or at least pressure to take on a maintenance burden, for other projects which wish to drop Python 2 and make use of new features only available in Python 3, since PyPy’s continued offering and support of an end-user-deliverable Python 2 interpreter would extend the life of software that is only compatible with Python 2.
This is the point I was making above, as a way of reminding you that while you’re complaining about the impact of the CPython/PSF messaging on you, you’re neglecting the impact of your messaging on others.
Also, I do wonder whether PyPy is really prepared to take on the burden of maintaining a high-profile Python 2 interpreter over potentially very long time scales, given the resource constraints which already have prevented being able to move it to bootstrap from Python 3.
Finally:
The alternative is to force the maintainers to continue supporting software they don’t want to support. For my own projects, I’m supporting Python 2 until 2020-01-01, and then I’m done and will enjoy getting to finally start using features of Python 3. While I have some sympathy for people who are still immovably on Python 2, I don’t feel any obligation, nearly 12 years after Python 3 was released, to continue maintaining things for them for free.
They will wave their totalitarian hand over the open source and free software they have released with the right for anyone to do with as they please and say “magically, we will destroy your ability to yourself do as you please with this software we don’t want anymore” and then we will all weep our crocodile tears as open source python has been cancelled.
Rest in peace, Python
Idk when - 2019
We will never forget, we will never forgive
Because they no longer wish to volunteer their time and effort keeping your software running for you.
Want to keep python 2 alive? Step up and do it.
I already contribute to PyPy and am hoping to switch nixpkgs to PyPy instead of CPython as the default Python 2 interpreter.
Why must PSF “sunset” our community?
Because they don’t want to release updates for you. You just have to do it yourself now, as you had before.
What do you propose they do then? Extend Python 2 support forever and let Python 2 slow down Python 3 development for all time?
What do you suggest they do about the real problem that it’s confusing for new programmers and users, and annoying for experienced programmers and users, that there are two Python dialects? Should Python programmers just forever have to decide between limiting themselves to writing code compatible with both Python 2 and Python 3, or writing code which a lot of users can’t run?
I get the feeling that you think they should’ve just made backwards-compatible improvements to Python 2 rather than breaking it with a major release of the language, and maybe that would’ve been better, but that’s not what they did. Therefore, I’m curious about what you would want them to do given the current situation, not what they should have done a decade ago.
What they should do now, given the current situation, is admit that PyPy is a reasonable implementation of Python 2, and admit that CPython’s demise does not doom the rest of the Python 2 ecosystem.
New Python programmers already must contend with the fact that the PSF publishes two manuals, one for Python 2 and one for Python 3, which look extremely similar, overlap greatly, and come up simultaneously in search results.
“First, PyPy’s toolchain, RPython, requires a Python 2.7 interpreter in order to bootstrap.”
That’s them choosing and forever staying on a specific dependency. We generally don’t force suppliers to support anyone doing that unless they’re customers paying for backward compatibility. Even then suppliers might not find it worth their time and effort.
Let’s say we address the dependency. Is it really that difficult for Python programmers to rewrite one Python program in the newer version of Python? That versus the effort to maintain and polish Python itself for just that dependency?
Seems more fair for the project that wants the dependency to be the one reworking it. Also fairer division of labor given other option is an externality.
“Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.
Yes. Additionally, you clearly don’t know either dialect of Python, and you clearly have not done such a port. I encourage you to do so! You will learn a lot. You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. For RPython, I would say that it is infeasible and not worth attempting unless somebody is paying.
““Supplier” is a bad term. The PyPy team is the RPython team, and they supply their own Python 2 implementation.”
Your original claim was about the Python Foundation, which you said backed CPython, was sunsetting support for Python 2 after telling everyone they’d do it for a long time. They were putting all their effort into Python 3. You then said this was a problem since another team, PyPy team, had a dependency on Python 2, had no intention to change that due to one component, did their own implementation of Python 2, and would stay on it.
That means this is an externality for PyPy, costing Python Foundation, where some other group is expected to support a language and its associated ecosystem just because of their dependency choices and porting preferences. I don’t see anything wrong with the other group saying, “No, we and our foundation have moved on in what we think are better directions. Anyone wanting to support the legacy tech can feel free. It’s on them since it’s not benefiting us.” Just going by what facts you’ve given here.
“you clearly don’t know either dialect of Python”
I used one here and there a long time ago. Don’t know either currently. I’ve been reading about Python 2 maybe getting ditched for Python 3 in these forums for a long time. So, I started asking some questions.
“You will mostly learn that Python 2 to Python 3 is not automatic, not trivial, and can take months at a minimum. “
Likewise, supporting an entire language, its libraries, security fixes, etc so some other people don’t have to port code is probably manual, less trivial than one component, and will drag on for years to decades. I’ve seen lots of companies port Python to Go. A Python to different kind of Python port of one component by Python experts is probably easier than maintaining a whole implementation of Python and its libraries. Just a guess.
If PSF is doing it for PSF, then by all means maybe they should maintain a whole platform. It’s different if it’s a lot of work, an externality for someone else, and they refuse to do a smaller set of work on their end. Again, just going by what you’ve described. If the facts are different, then this analysis would be wrong.
You are equating the support from PSF of Python 2 with the existence of any Python 2 interpreter. If, tomorrow, all CPython 2.x installations stopped working, PyPy users would nonetheless still be able to execute pip or another pure-Python package manager and download Python 2 packages from PSF-operated infrastructure. This is an example of the sort of non-CPython-specific support for the entire Python community under PSF’s control.
The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.
Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence. Many folks simply wanted Python 2 to become Python 3, a fantasy paid for with developer-hours.
“The PyPy team can, and will, and must, support their entire toolchain, including RPython, PyPy, and a copy of the Python parts of CPython’s standard library.”
That’s on them is my point. If they want PSF support, they need to give them a reason that works to their liking. If not, ignore them with a marketing strategy and/or foundation of their own that supports their goals. That’s how these things work.
“Please ensure that your facts include the corporate employers of various CPython core developers, as well as GvR’s unyielding shadowy influence.”
Sure. If corporations and GvR are in control, then CPython development needs to continue to reflect what they want out of pragmatism or expect lots of failure. Anyone not liking the decisions of those corporations and GvR should fork Python totally to support their vision with their own resources with no hate or aggravation toward the others acting in their own self interests. Maybe even out-compete them with their own language extensions and/or higher-performance implementations [1] on top of better marketing strategy and funding outreach. The kinds of things developers and organizers did for older versions of Python to get them where they were.
Edit: [1] Adding that Nim and Julia are sort of doing that already even though I meant an improved version of Python. Nim has Python-like syntax with extra features and higher-performance during runtime. Its getting some Python users. Python is entrenched in scientific computing. Julia is grabbing some of those people with alternative design, focus on higher performance, and focus on easier integration with C libraries while still keeping Python ones. They’re both getting users with Julia getting a lot of them.
This isn’t about PSF support, although if we’re going to talk about PSF support, it’s notable that the total sum investment of the PSF in PyPy is $10,000. I can guess at the salaries of the typical CPython core developer, and they’re a little better than five figures. It was only a year or two ago that PSF even opened up their grant program to allowing PyPy, Jython, or other non-CPython-based projects to apply for grant money.
This is about the words at the top of the original post. To remind:
These words purport to speak for PyPy’s team and any other Python 2 team. These words claim that Python 2 will be removed from our hands next year. Can you grok this? Do you understand why it might be a bit of a problem that the group that sits on the pile of money and trademarks has unilaterally decided that entire branches of the family tree must be pruned?
Not Nim, but indeed Julia, as well as my own Monte, Hy, Quill, Lever, and likely others, all came from the realization over half a decade ago that the PSF was disowning Python 2 and would only acknowledge Python 3 as the one true Python. If we’re not going to keep the name, why keep the semantics? We could improve.
The original post was published on python.org, which has an SSL cert published by the Python Software Foundation. It’s published by the PSF and speaks for them.
You are making weird semantic shifts between “Python the language”, “Python the implementation”, and “Python the trademark” all over the place.
It’s clear you (and maybe the rest of PyPy) have no love for Guido van Rossum, and maybe not the PSF. But the fact is that they own the trademark to Python. Trademarks exist in part to prevent customers from confusing one product for another. That way, no-one will be confused when the code they get from the PSF (Python 3) won’t run on PyPy (Python 2).
That said, I’m sure no-one would object to say a product called “PyPy - a version of the Python language and runtime based on Python version 2.7”.
From what I’ve read in this thread, it seems that PyPy wants to have their cake and eat it - they want full and continued support from the PSF for Python 2, while at the same time being entirely separate from them and not have to follow the PSF in any other matter. I really don’t see why the PSF has to go along with this arrangement.
This is a sticky wicket, and it’s by no means unique to Python. Witness the difficulty non standard Ruby, Perl etc. implementations have had keeping up with the reference implementation.
In the end, a most language communities end up, as Guido/Python did, deciding to focus on one implementation and say “This is THE reference implementation of the language”.
Doing anything else requires a massive outlay of man hours that just don’t exist in communities like Python - you’d need something like the Jave TCK.
This is not a fair reading of what Guido actually said in that issue. He is talking about PyPy being an alternative to Python 2, and being disappointed they’re not implementing Python 3. He didn’t mention anything about Python being “unified under a single holistic banner” or PyPy being a “threat”
It’s totally understandable that you dislike my opinion. This is a synthetic opinion of GvR’s desires that comes not just from this post, but from years of interactions with him, including a particularly memorable dinner from a PyCon in Montreal a few years ago.
PyPy is not just an alternative to Python 2; there is a Python 3 branch. Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy. I can’t imagine that his disappointment is that PyPy doesn’t have Python 3 support, but more likely that PyPy exists at all and mars the otherwise-singular transition between languages.
PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers. We sometimes like to imagine a world where Python interpreters were fast, but this is apparently not that world.
For me, peak-PyPy and excitement around alternative implementations happened in the 2008-2012 window. What I mean by this, is that everyone was excited about alternative implementations driving performance forward at a time when folks weren’t so worried about Python 3 compatibility, and Python itself was just getting into a growth curve. I’d cite Dave Beazley’s PyCon Keynote at PyCon 2012 as an example of how PyPy wasn’t sidelined to the degree you argue it is.
Fast forward a few years and folks are in the trough of disillusionment, to steal a phrase from tech analysts. There were lots of (invalid, but) broken expectations in the community. Unladen Swallow, Jython, IronPython, and PyPy (to name just a few) hadn’t taken the world by storm and we were still trying to remove the GIL without breaking C extension compatibility. There were a lot of good intentions about getting and staying compatible with the Python mainstream - but this didn’t happen, and the alternative implementations got behind. PyPy’s history of Python 3 funding has some relevant detail.
It’s great that PyPy has caught up, but there is some way to go as far as being a strategic choice for folks. Even with CPython’s pretty obvious deficiencies it’s been able to carry a community forward to a place that’s very different from 2008. PyPy can make the argument that it’s a viable and supported Python 2 that could even get better, but very few people want this, even if they have to support Python 2. Python developers for the most part want to move to Python 3 because it’s finally a compelling option. In my mind, it’d be better if PyPy adapted to the current environment and attempted to overtake CPython as the platform of choice for Python 3 instead of fighting old battles for a diminishing platform.
Sure, you’re part of one arm of the massive galaxy of Python. However, you should know that there is another arm, where:
There is a clear difference between Unladen, Pyjion, Pyston, etc. vs PyPy: PyPy is a true community project, not a corporate timewaster. If that makes it less strategic, so be it; the clear difference is that PyPy ships, and has been shipping for years. In 2008, it was already shipping, already fast, and the PyPy position was that CPython folks should keep CPython as the reference interpreter, but encourage PyPy and Jython experimentation, deprecate the C API, and encourage platform-neutral portable Python. This position of ours is over a decade old.
“Indeed, the main PyPy page offers 2.7.13, 3.5.3, and 3.6.x versions of PyPy.”
They’ve done a lot of work. They deserve more visibility. I’ve always mentioned them to people interested in Python implementations.
“PyPy has never, to my knowledge, cracked 5% of all Python usage. The only measurements I’ve seen have come up at 1-2%. It has always been marginalized due to the desires of CPython core developers.”
The desires of a project’s developers rarely determine what massive amounts of people in the real world do. Especially across many disciplines that we see Python in. That’s marketing, what default binaries are available in package managers, what people in charge prefer, what gets the most press, word of mouth pushing each person’s favored version, etc. These things drive language adoption on large scales.
The core Python team has a good brand and product they got bundled in most Linux distro’s by default with almost anything people read about Python pointing them in that direction. That’s why most use something like that vs PyPy. The PyPy team would have to step up big time on all the non-technical things that help achieve market success. Especially working with major distro’s to bundle them instead of reference Python. I don’t know what they’ve done on any of that since I just occasionally looked at the project being impressed at the technical work they put in.
I need to quote a PyPy developer. They contribute quite a bit of code, but crucially rely on funding, either from community awards or from paid consulting, to make their living. Their reaction upon reading GvR’s words earlier:
As for distro involvement, all of the big distros (Debian, Fedora, Gentoo, OpenSUSE) have a PyPy package of some sort. It’s second-class in many distros, because the core packages of the system are written specifically for CPython.
Many many PyCon hallway discussions have been expended over this. I know that, as an outsider, it seems like this is a matter of marketing or some other intangible/bullshit matter of business, but inside the Python ecosystem, there has grown to be a vast divide between those of us focused on speed in Python and speed beside Python. We former have always been willing to accept being second-class to some extent, but here we are asked to abide a terrible distortion of reality where Python 2 and Python 3 are equivocated in order to fulfill the prophecy and consolidate power over both languages.
I am enjoying your explanations, and lament your suffering, and if I had a clue, I might also have an opinion. But I just want to point out that I think when you grabbed the word “equivocated,” you were really reaching for “equated.” The way you have it reads as tho both the languages are being “made into mistakes.”
If you meant it in the sense of “hide the truth,” then that should be something being done by people. “To equivocate” cannot take a direct object. CPython partisans may equivocate about Python versions, but the versions may not be equivocated by somebody (only truth in general can “be equivocated,” and to so state is tautological to the point of ungrammaticality) nor may they themselves equivocate (unless it’s anthropomorphism, which makes sense, e.g. Python 2 equivocates about strings being Unicode or bytes).
Thanks for taking the time to reply. I can see from the language you’re using is that this is not just a technical matter, there are deep personal disagreements at play on both sides which makes this transition so hard.
I just have two followup questions related to the future of PyPy
To your first question: No; see for yourself. Some features are neutral, some features are harmful. When it comes to RPython, the language is already restricted compared to Python 2, because the whole program is subject to type inference. Python 3 doesn’t offer any features which support type inference. (Annotations don’t help type inference more than actual code!) Some features, like ordered dictionaries by default, were first developed in PyPy and then copied by CPython later.
There is exactly one feature worth borrowing from Python 3, f-strings, but don’t bother. Python 3 gained them around the same time that ECMAScript gained template literals. Of course, in the original languages Scheme and E where the technique was pioneered, these templating strings can be used not just as builders of values, but also as patterns which destruct values. And in E, it is possible to customize how the value is built, by writing a custom builder. However, in Python 3, f-strings cannot be used as patterns, nor can custom builders be used. I asked somebody involved in drafting that PEP why the feature wasn’t lifted in toto, and they replied that nobody else in the room of CPython core developers had understood why it would be useful.
To your second bullet point, yes, there is a possible world where PyPy jumps from less than 5% usage this year to over 50% next year for Python 2. I don’t know whether that world is going to happen, because I believe that the PSF will put in effort to prevent Python 2 ecosystems from flourishing without their permission.
But funnily enough I expect that we’re likely to see tools to analyze codebases for safety to port to PyPy for this reason; and one-and-done solutions for adapting c-based packages to work with PyPy.
That or blog posts from the interested parties explaining why that’s so infeasible that they’re finding CPython 2.7 security.
PyPy is a compliant implementation of Python. There are documented differences from CPython, but in general, you should be able to write pure Python and have it work with PyPy.
The main barrier to PyPy adoption is the continued existence of CPython’s C API.
More or less all scientific and data science users of python use libraries that depend on the CPython C API.
For them, PyPy is not a useful alternative.
Besides that, as they say in the announcement, many open source projects will stop supporting python 2. They’ll do that because it is work to support python 2 and they prefer to use or be compatible with 3.
PyPy has reasonable support for python 3 and the py2.7 required for bootstrapping can be maintained or replaced - it’s not like it needs any bug or security fixes for this purpose.
Right. Which is why you’d want to analyse your codebase for both use of c-based libraries and the weird dumb things you would do hit those documented differences.
The fact that print ‘foo’ no longer works in python 3 is the most annoying change. There’s no reason for it, and almost 100% of my code would run fine on python 3 if not for it.
Python is so lucky they won the mindshare war. This upgrade has been a mess.
Speaking as someone who is going through a long delayed upgrade from 2 to 3 at the moment, if print becoming a function is the biggest issue you will have, you would have no problem just running 2to3 and being done with it.
But print is probably not the issue. For us, it’s been the distinction between bytes and string (or, that our codebase relied on the lack of distinction in python 2).
Ah yeah, excellent point. I’ve run into that too, especially with stdout/stdin.
Then use 2to3 and continue with Python3.
Fixing mistakes is often like that. :-/