Someone linked to Amber Brown's talk and I thought this point would be important for discussion. I think there is something that isn't being considered here when it comes to relying on PyPi.
3PP(Third Party Packages) issues are responsible for a lot of application security vulnerabilities today. Every large enterprise organization has no idea what packages a developer is pulling onto their laptop and into their codebase.
As a security engineer, I like having a core team and a standard library in place that has gone through a long mature process with experienced developers, instead of someone who just git pushes code every night. You have no idea who is on the other end of that push too. It's too hard to keep track of changes and causes us to have to pin packages and versions that have been ok'd for use instead of a new release of Python. You have no guarantee the security engineer who reviewed the code didn't miss anything either.
Hmm, should perhaps this be worthy of a major version number bump? Yes, it's not as large or as breaking of a change as the 2.7->3.0 transition, but by removing modules from the standard library, backwards compatibility is being broken. Now, perhaps most people don't use those features anymore, but for those people who do use and rely on these modules, a major version number change would be a welcome signal that their code will no longer work with the new version.
But, after the initial pain of the 2.7->3.0 transition, I doubt we'll ever see another major version number jump, even if a logical use of version numbers would merit it.
Relevant discussion 4 days ago, "Python's batteries are leaking": https://news.ycombinator.com/item?id=19948642
> Modules in the standard library are generally favored and seen as the de-facto solution for a problem. A majority of users only pick 3rd party modules to replace a stdlib module, when they have a compelling reason, e.g. lxml instead of xml. The removal of an unmaintained stdlib module increases the chances of a community contributed module to become widely used.
Developers don't have a compelling reason to use 3rd party modules instead of the standard library. Therefore they don't. You consider that a problem and want to encourage them to use 3rd party modules more.
In short, you want developers to use 3rd party libraries because there is no compelling reason to do so?
> A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit). Python on mobile platforms like BeeWare or WebAssembly (e.g. pyodide) also benefit from reduced download size.
That's a silly reason. Just make a separate distribution with a stripped down standard library.
Since the parser module is documented as deprecated since Python 2.5 and a new parsing technology is planned for 3.9, the parser module is scheduled for removal in 3.9.
Hm interesting comment. Does anybody know what the new approach to parsing Python in 3.9 is ? I searched python-dev@ but couldn't find any references to it.
I found an interesting tidbit about Rust "switching" from LL to LR here:
https://www.reddit.com/r/ProgrammingLanguages/comments/brhdt...
And I noticed some rules in Python's grammar that are awkward in LL parsing (set and dict literals, and comprehensions).
I wonder if those things motivated the switch? They certainly work though.
> Times have changed. The introduction of the cheese shop (PyPI), setuptools, and later pip, it became simple and straight forward to download and install packages.
I’ve been out of the Python loop for a few years, but my last impression was that packaging and distribution of Python modules was far from a solved problem. Has this changed?
> A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit). Python on mobile platforms like BeeWare or WebAssembly (e.g. pyodide) also benefit from reduced download size.
Python, lean and mean? Seems like an incredibly niche use case to restrict the python community to.
Considering how many different types of data have and can be stored in IFF chunks (and their order-swapped RIFF counterparts) I'm almost insulted by the PEP author considering IFF to just be "an old audio file format".
I think my Commodore/Amiga persecution complex is acting up again.
> 3.8.0b1 is scheduled to be release shortly after the PEP is officially submitted. Since it's improbable that the PEP will pass all stages of the PEP process in time, I propose a two step acceptance process that is analogous Python's two release deprecation process.
Why should this be fast-tracked outside the normal process? I can’t imagine any of these removals are urgent.
If we're going to lean more on PyPI, it would be nice to clean it up some. There's a lot of cruft that makes it very hard to find the right module to use to write a new project with. And it would be nice if package naming convention were more standard, and suggested extending existing modules rather than writing entirely new ones. If you want HTTP functionality, you use the "requests" package, which uses urllib3. Why not io::net::http::client, extending io::net::http, and so on?
Some batteries are surprising https://docs.python.org/3/library/
difflib - Text diffs, even html output
textwrap - obvious no?
rlcompleter - autocomplete symbols and identifiers, used in interactive mode
pprint - for printing complex data structures with indentation
reprlib - repr with traversal depth and string size limits fraction - Fraction('-.125') becomes Fraction(-1, 8)
statistics - averages and deviances tempfile — Generate temporary files and directories
glob — Unix style pathname pattern expansion
gzip, bz2, zipfile, tarfile - obvious
configparser - ini-like format
secrets - use this instead of random for safe cryptography
sched — Event scheduler
turtle — Turtle graphics
shlex — Simple lexical analysis
webbrowser — Convenient Web-browser controller, for the antigravity module!
MSI support removal seems premature. Can you do unsandboxed stuff from an AppX? Also can you install AppXs on Windows 7/8?
The only thing I worry about is the uu module. Even though 99.99% of people will never use it, there are also probably literally millions if not billions of pieces of content that are encoded using that standard. I realize it's only a few lines of code, but from an archival perspective it seems like there's something distasteful about making it harder for future generations to access content that may have historical value. At least send a quick note to the library of congress or the archivist community first to get an idea of to what extent this stuff is getting used.
I honestly didn't realize there was so much random stuff in stdlib.
This seems like a vast swath of things to deprecate with one PEP, but it looks like the author of the PEP talked with a large number of core developers about issues that they had with the stdlib and decided deprecated packages that way, which I think should be good for approval of the PEP.
I have a couple of questions:
- I realize there may not be a fork with this PEP implemented, but how might this impact Python's local relative build time, and how might that convert over to the build pipelines? Drastically faster build times would be really nice.
- Are Python 2 -> 3 migrations for stdlib packages mostly rewrites or mostly tacking on compatibility layers like `from __future__ import unicode_literals`? If stdlib packages were updated with Python 3 syntax, it might indicate sustained demand for said package going forward. I'm not sure.
https://docs.python.org/3/library/fileinput.html
I've never had a strong opinion about "batteries included", but boy there are some weird ones in there...
My one objection to this is the `imp` module. As far as I can tell it is the only way (short of `sys.path` modification) to specifically load a module found at a specific path. For testing systems I use this quite extensively... Looks like I need to make some comments...
I love this. I hope more and more cruft gets removed from our languages and tools.
This has been a long time coming and I'm surprised it's taken until 2019. A better time to have done this would have been back at the 2-3 migration; I'm not sure the community will be able to survive another transition like that, but hopefully lessons have been learned from the previous schism. A step in the right direction for sure!
Just one data point here, but with the exception of the cgi module a long time ago, I haven’t used any of these modules in the past 15 years of web programming, ETL scripts, or data processing. In the keep list, I’ve used fileinput once that I can remember.
I think an 80/20 solution is documentation UX. Just take all these old modules and put them into an "old modules" section and preface that section with a short discussion on what this all means and what the wisdom is.
noo not the cgi module :(
I'm surprised at the removal of aifc. AIFF is still used somewhat in macOS.
My only concern with this is that they won't be made available on Pypi for those that still need it. They will pull out the code but they expect the community to package it back up and make it available. Their hope is that the community will improve it before making it available, but I suspect the reality will be that the moment it is deprecated, someone will just go through and make all of them available in Pypi exactly as is.
audioop is an interesting little thingy.
For example-- why does "add" add two fragments, but "mul" multiplies one fragment by a scalar value? Was the assumption that "mul" will probably just be used for attenuation?
It would be fun to build a tk-based audio app around audioop for the sole purpose of complaining about the deprecation of this module. :)
This seems like a good idea to me, but what are the chances that something like this actually lands? I know Guido did not seem to like this approach (to put it mildly), although I'm not sure he still has veto power having stepped down as BDFL.
Also, the changes sound like a major version bump to me, but I doubt people want that to happen after Python 2 to 3...
Serious question - Why put off DeprecationWarnings to 3.9? If these modules are as dead as this PEP claims, then I'd wonder if Python scripts using such modules would be actively looking to transition to 3.x in the first place.
Very practical move!
I think few other legacy platforms Java(JDK), JS(NodeJS), Ruby etc. also in need of this kind of refactoring exercise and removing the old cruft.
It feels like this PEP should have more practical examples of how these modules are impacting the work of core Python developers. Some number of bug reports or time spent dealing with them.
Many ridiculous suggestions, like the whole "data encoding" group (obsolete data formats don't need maintenance) and the various modules about old file formats (ditto).
Again, Tkinter isn't on the hit list and I'm glad.
Old people stuff below:
I guess we're getting to the point where people now say things like "it was developed for TSR-80", where it is more correct to say "for the TSR-80." :)
> The uu module provides uuencode format, an old binary encoding format for email from 1980.
while true, uu was also used extensively in usenet, at least throughout 1997. But as we learn later, noone has touched nntp code in 5 years! and there is no interest in porting nntplib to py3.
> originally introduced for Commodore and Amiga. The format is no longer relevant.
not disagreeing. Just saying "ouch."
> The module only supports AU, AIFF, HCOM, VOC, WAV, and other ancient formats.
Again, not disagreeing, but implies .wav is ancient. It's still in heavy use (they're keeping "wave"). And ancient is hyperbolic and slightly insulting, but I'm just going to let it go as humor in service of persuasoin. It's hard to let go sometimes when these formats provided so much joy and delight in such a pure fashion. Particularly AIFF vs WAV.
AIFF was for Amigas and Macs. Lots of great early techno used that format, while clumsy windows machines used .wav and lagged seriously in music software. Life then was more natural and computers were these shiny, productive boxes of creativity. We sat down at them for an hour at a time and expressed wonderful songs. Then got up and lived life. I don't need to mention that we now spend almost all day and all night inside a computer, at its keyboard or tablet, its screen and increasingly its headphones. Instead of augmenting our lives like a microwave, they "shelter" us.
I know the tools are objectively better now. They're more reliable, more productive and have more features. But I disagree that they provide more of what we actually need as human beings. Thinking like a designer, we need nourishing human experiences, challenges and interactions. We need opportunities to use our bodies physically, to run and cook, and especially to work, play and function together. But our health is objectively decreasing. Suicide is on the rise in several demographics. We're spending more time e-socializing so we eat more fast food. Obesity is on the rise. We can't even put the darn things down to drive.
Traditionally, human functioning meant organizing socially in groups that combined strangers' abilities. It required us to have patience and instruct each other. Increasingly, computers/apps/networks give us all the same concentrated superpowers. Now I can find any recipe I want, but I don't have anyone to cook it with. Our interactions are increasingly mediated, robotizing our communication. All this pausing caused by http-to-sql operations after every mouse click or sentence stilts us. It's almost as if our world is more black and white and lower resolution because we're experiencing so much of it through a densely mediated stack.
I'll also point out that in the old days, a library that supported five formats was a flipping miracle. But time marches on.
Having watched and been part of this whole python and internet phenomenon, experiencing it rise from nowhere and evolve from a neato thing into a mechanized, hyper-official "means of production" this is somewhat emotional for me. Guess I'm just getting old and I'll suck it up, but I just want to write these notes for people who wonder about what life was like before, or forget to wonder.
See the video of most dangerous bird and how he killed owner https://howto105.blogspot.com/2019/04/most-dangerous-bird-ki...
Funny dog driving own car See his video on link below http://bit.ly/2WdSKpA
Cute dog going for school like human baby see his cute video I am sure you can't stop laugh http://bit.ly/2Wq6Ynr
United nation recently showed the real face of india See what they said in report After knowing this I am sure you will hate them if you have soft heart https://youtu.be/oUskNtdWeIY
Best way to get rid from face moles with the help of home remedies its easy and simple way You don't need to waste money for this https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-fa...
This really, really, bothers me. The rationale seems absurd. Is there no more uu encoded data in the world? Throwing this code away is a recipe for a future where some data is never recoverable. Python is a swiss army knife. The imagination that pypi is going to survive forever and be accessible forever is absurd. A programming language that throws away the past is doomed to become a passing fad. If the code is old who cares as long as it still works?
Nobody talks much about the original goal of "There should be one-- and preferably only one --obvious way to do it." -- PEP 20 (!)
Back when, I lurved me some Perl TMTOWTDI as much as the next guy--plenty of uses for such a thing in a Swiss army chain saw--but then Python had a good (or at least different) answer to that by reducing the language load and focusing more on the problem.
So tell me, how many string formatters do we have now? Could we please decruft and dump some of them while we're at it? % or f' or .format or whatever, but please just pick one and get the rest out of my face.
https://www.python.org/dev/peps/pep-0020/
https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...