39 ms·
PEP 594 – Removing dead batteries from Python's standard library
- avar 7y agoRelevant discussion 4 days ago, "Python's batteries are leaking": https://news.ycombinator.com/item?id=19948642 https://news.ycombinator.com/item?id=19948642
- jstimpfle 7y agohttps://docs.python.org/3/library/fileinput.html 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...
- ehsankia 7y agoEspecially when you start looking at the code for some of these https://github.com/python/cpython/blob/master/Lib/imghdr.py https://github.com/python/cpython/blob/master/Lib/imghdr.py
- Znafon 7y agoTo be fair, it dates from 1992. I don't think PyPi existed at the time, it's rather impressive the Core team supported this for so long.
- tomjakubowski 7y agoRuby includes something similar, ARGF. It's pretty useful over there. https://thoughtbot.com/blog/rubys-argf https://thoughtbot.com/blog/rubys-argf
- jstimpfle 7y agoWell, maybe fileinput is meant to be used for making shell one-liners using the -m switch or so, like in the link you posted, or like perl/awk. Does that play nice with Python's block syntax, though?
- mftrhu 7y agoWhy do you think fileinput is weird?
- jstimpfle 7y agoThe functionality is almost less than trivial. It's like, trading 3 lines of super straightforward code for one line of import statement and a library dependency. Pretty sure it tries to emulate awk's programming model, but even if I had a use for that I'd rather write these 3 lines of code myself - so the code is actually clear without looking at documentation, and so that it can be modified easily.
- naniwaduni 7y agoFilters over lines of text may be domain-specific, but it sure as hell spans a lot of domains.
- jstimpfle 7y agoIdk, it never occurred to me the need for a library that does more than "for line in sys.stdin:" but less than what you can easily write in under a minute.
- rabidrat 7y agoIt handles files being passed on the command line too. Your particular usage might only take a minute, but to make it play nice with other expected CLI usages, takes more thought (and you will probably forget something).
- masklinn 7y ago> Idk, it never occurred to me the need for a library that does more than "for line in sys.stdin:" Of course if you'd only used fileinput for that it would be worthless. However what it does is way more useful, namely iterate on the lines of all files provided as parameter (or sys.argv[:1]), fallback to sys.stdin if no files were provided, and swap the special sentinel `-` by sys.stdin.
- ehsankia 7y agoI honestly didn't realize there was so much random stuff in stdlib.
- varelaz 7y agoThere are much more of it. I think around 1/3 of standard library is legacy and burden for python. I recall there was a PyCon talk about why you may not want to be a part of standard library. Release process and support of old versions is very strict and heavy, it could delay releases and API change dramatically. You can look at situation with urllib for example, there are 3 versions of them, but most popular is requests 3rd party module.
- icodestuff 7y agoI'm surprised at the removal of aifc. AIFF is still used somewhat in macOS.
- coldtea 7y agoWell, they don't remove AIFF tho, just the lib -- which presumably nobody uses...
- schrijver 7y agoAIFF is used widely in audio production software; for exporting uncompressed audio many application default to AIFF. It’s the most universally useful lossless format; WAV support is ubiquitous too but AIFF has better metadata. FLAC and ALAC are good alternatives today, but not on the same level of support yet. For example, for purposes of price differentiation, Pioneer reserves FLAC and ALAC support for their most expensive digital turntables. If you’re writing a Python script that outputs an audio file, outputting to AIFF seems like a save bet. Then again I’m not sure how many people are actually using the module from the stdlib--but neither does the PEP’s author, it seems. His level of research was asking his friends on Twitter: https://twitter.com/ChristianHeimes/status/1130257799475335169 https://twitter.com/ChristianHeimes/status/11302577994753351...
- dlbucci 7y agoThis 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...
- stOneskull 7y agocan you step down from something that is for life?
- deleted 7y ago[deleted]
- Macha 7y agoI'm not sure Guido's argument was with the argument indicating some stdlib parts are outdated as the argument that new library features are not worth using because twisted wants to support python 2
- jsmeaton 7y agoGuido can not veto, but the PEP still needs to be confirmed by the steering council[0] of which Guido is a member. [0]https://www.python.org/dev/peps/pep-8100/#results https://www.python.org/dev/peps/pep-8100/#results
- yingw787 7y agoThis 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.
- Znafon 7y ago> Are Python 2 -> 3 migrations for stdlib packages mostly rewrites or mostly tacking on compatibility layers like `from __future__ import unicode_literals`? Packages in the stdlib don't need compatibility layer since they are always used with the Python version they were written for, it's motly incremental rewrites. Regarding the build time, I don't think most of the time is spent testing those parts of the stdlib.
- enedil 7y agoI'm not the OP, but I suspect that what was means was backporting features to py2.7, which presumably use some new Python 3 which haven't been built in the old language version.
- simcop2387 7y agoI don't think that back porting features to 2.7 it's in anyone's radar anymore given that it goes end of life in just over 7 months. Anything that isn't already there is likely not going to benefit many people
- Dylan16807 7y ago
- monocasa 7y agoMSI support removal seems premature. Can you do unsandboxed stuff from an AppX? Also can you install AppXs on Windows 7/8?
- chungy 7y agoHow many people actually used Python's MSI library? It was Windows-only (presumably a wrapper around the native tooling), and was primarily for creating Python's own installer, which apparently doesn't get built as an MSI anymore.
- ptx 7y agoI use it for packaging my Python application. But it seems pretty low-level, so I suppose I could call the win32 API directly through ctypes when they remove it.
- WorldMaker 7y agoYou've been able to do Win32 stuff in an AppX since early in Windows 10 history, it's mostly "unsandboxed". MSIX, the "new" AppX, has Windows 7/8 support for Win32-focused installs in preview. Semi-relatedly, Microsoft has already been exploring with the Python team MSIX deployments for the Python interpreter itself (you can even find it in the Microsoft Store now on Windows 10, and typing `python` on a command line in recent builds of Windows 10 will auto jump you to the Store if you don't have a python.exe in your PATH/installed).
- WorldMaker 7y ago(Also, getting in the weeds, the "mostly unsandboxed" refers to that MSIX installs will do a few things to insure at all costs clean uninstall, including system folder virtualization/redirection, registry virtualization/redirection, and similar techniques. Windows and MSI has been doing a lot of this sort of thing under-the-hood silently since XP as a part of compatibility work, MSIX just does it more obviously/automatically/always.)
- leothekim 7y agoSerious 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.
- puetzk 7y agoBecause the 3.8 beta (and hence 3.8 feature freeze) is next week, and there's basically no chance of completing the PEP in time to make that cutoff.
- korethr 7y agoHmm, 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.
- enedil 7y agoIt's also quite possible, that the people who use these features use Python 2 anyway.
- mjevans 7y agoDoes this mean we're going to have Python 2 installed on things forever? (Particularly anything that touches NNTP servers, as there's no replacement for that lib)
- earenndil 7y agoWhich lib?
- anoncake 7y agoThe one for touching NNTP servers.
- viraptor 7y agoIt's simple code. It can be moved to a separate package and imported with the same name.
- u801e 7y agoIf it's simple, then what's the point in removing it? Dealing with standard application level protocols like SMTP, NNTP, FTP, IMAP, POP, and HTTP shouldn't require installing third party packages.
- mleonhard 7y agoI love this. I hope more and more cruft gets removed from our languages and tools.
- Alex3917 7y agoThe 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.
- roblabla 7y agoThis module is pure python. It looks like if people rely on it, they could easily put the code in a pypi module, and maintain it there. It doesn't really make sense to keep it in the core if it has no dedicated maintainers.
- takeda 7y agoThat code doesn't need any maintainers, it is not like UU encoding is evolving or really complex.
- guitarbill 7y agoThat's a bit dramatic. Our knowledge of the encoding doesn't go away because Python removed support. Old versions will continue to work. The code is preserved in VCS. And finally, you/someone can release a 3rd party module to PyPI to fill the gap.
- naniwaduni 7y agoThe useful functionality (encoding/decoding) is covered by binascii, which uu in fact uses internally. What the uu module proper provides is a pair of awful file-to-file interfaces. Default to spitting the decoded file directly to disk at with the name in its header is, uh, questionable.
- owaislone 7y agoIsn't it just being removed from the standard library? It can still exist on pypi especially if it is as important as you suggest, someone will definitely host it on pypi.
- sara7262 7y agoSee the video of most dangerous bird and how he killed owner https://howto105.blogspot.com/2019/04/most-dangerous-bird-killed-owner-in-usa.html 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 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 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 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-face-moles-with.html https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-fa...
- coldacid 7y agoConsidering 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.
- 0xADEADBEE 7y agoThis 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!
- jancsika 7y agoaudioop 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. :)
- larkost 7y agoMy 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...
- tgb 7y agoI use imp.reload(my_module) all the time when %run-ing things from ipython that import my_module after editing it. What's the alternative for that use?
- saila 7y agoYou can do that with importlib too: from importlib.machinery import SourceFileLoader
- ChrisSD 7y agoThat's been deprecated as well. The current docs say you should do this spec = importlib.util.spec_from_file_location(module_name, file_path) module = importlib.util.module_from_spec(spec) spec.loader.exec_module(module) https://docs.python.org/3/library/importlib.html#importing-a-source-file-directly https://docs.python.org/3/library/importlib.html#importing-a...
- comex 7y agoGross...
- deleted 7y ago
- saila 7y agoJust 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.
- peterwwillis 7y agoIf 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?
- torlakur 7y agoWell, that sounds like the package names (and namespaces) that the Perl 5 community have landed on with CPAN modules :)
- chubot 7y agoSince 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/brhdt2/notes_on_rusts_grammar_ll_vs_lr/ 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.
- why_only_15 7y agoIt appears that the ast module is the recommended one now.
- ivoflipse 7y agoThey're having the discussion on Discuss: https://discuss.python.org/t/preparing-for-new-python-parsing/1550/42 https://discuss.python.org/t/preparing-for-new-python-parsin...
- chubot 7y agoThanks a lot! That led me to find this November thread: https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379 https://discuss.python.org/t/switch-pythons-parsing-tech-to-... And I posted here about it: https://www.reddit.com/r/ProgrammingLanguages/comments/brz2yj/switch_pythons_parsing_tech_to_something_more/ https://www.reddit.com/r/ProgrammingLanguages/comments/brz2y... It looks like the set and dict literals I noticed weren't so much the motivating use cases, but even more fundamentally assignments and keyword args!
- scrollaway 7y agoHuh interesting. I've been using parsimonious for cases like this, didn't know python had a stdlib for it...
- nomel 7y ago> 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.
- yjftsjthsd-h 7y agoAt that point I'd expect to be using micropython anyways.
- deleted 7y ago[deleted]
- jedberg 7y agoMy 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.
- JeremyBanks 7y agoWhy is that a concern?
- analognoise 7y agoAgain, Tkinter isn't on the hit list and I'm glad.
- k4ch0w 7y agoSomeone 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.
- jahewson 7y agoThere’s really two separate concepts here: review and the standard library. Why not separate concerns and have a review process that isn’t coupled to the standard library? There’s no reason why any PyPI package can’t have meaningful reviews published. The question that you’re ultimately seeking the answer to is “what code has been reviewed and which reviewers do I trust?” - lots of ways to solve that.
- anoncake 7y agoOne reason for this proposal is to save manpower. Separating concerns doesn't help with that.
- anoncake 7y ago> 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.
- hoseja 7y agoThey want to stop supporting the old modules because to keep them in working order is almost useless and uses too much manpower.
- anoncake 7y agoThat's one of three reasons. https://www.python.org/dev/peps/pep-0594/#rationale https://www.python.org/dev/peps/pep-0594/#rationale
- deleted 7y ago[deleted]
- carlmr 7y ago>> 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. True, you could have a std and core library. I think Rust does this for embedded. IMHO if you take away the large standard lib, except for pandas I have no more reasons to use Python. I don't like the language that much, but the std library is pretty good for scripting when you need something on a target system that only has standard Python.
- jl6 7y ago> 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?
- carlmr 7y agoNo, it's still one of the worst package management systems out there. I'm always wondering if it has to do with the language and or just the package manager itself. Rust's cargo, Node's npm and probably quite a few others exist that work amazingly well.
- alexchamberlain 7y agoWhat makes it the worst? Is it non-pure Python extensions, or is there something missing for pure python packages too?
- lmm 7y agoIt's broken for pure python too. The standards were too heavily influenced by traditional unix sysadmins who love server-global libraries, so that's still the direction all the tooling guides you in despite being the worst way to work with Python. Every couple of years they rewrite it without fixing any of the problems. Sometimes they make it worse, as with e.g. moving pip into python. I struggle to imagine the decision-making process that could come up with these outcomes - surely they must be studying what works for other languages or there'd be no way they'd manage to avoid it all so perfectly.
- sametmax 7y agoNot anymore, .whl files are now similar to npm packages, with static metadata and just unpacked on pip installed. Most popular packages are .whl now.
- 7y ago
- aitchnyu 7y agoSome batteries are surprising https://docs.python.org/3/library/ 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!
- jimbo1qaz 7y agoLZMA is better than gzip i think. Also secrets deserves to stay in the library, Python has hashlib and it should have a secure RNG by default. glob too (or Path.glob). And I've used shlex for command-line-escape parsing (it might not have been the optimal solution?)
- masklinn 7y ago> LZMA is better than gzip i think. LZMA provides much better compression at much higher costs. Generally speaking it's pretty strictly better than bzip2, not necessarily gzip (DEFLATE, really). In my experience, zstd can be considered better than gzip/deflate (almost every time I tried it, it provided as-good-or-better compression at much faster throughput).
- maxnoe 7y agoYes, zstandard turned out to be the best option in all our tests on small to really large data (couple of mb to gigabytes filesize). A few percent better compression than gzip and nearly 50 % faster decompression. Gzip is pretty slow in the python standard lib. The python zstandard bindings unfortunately do not allow back seeking.
- 7y ago
- robobro 7y agonoo not the cgi module :(
- zestyping 7y agoI was wondering about that too. CGI is still just about the easiest and most universally supported way to serve dynamic web content from a Python script. The complaint is that the module is designed poorly, which is fair; to remove CGI support without any "batteries included" replacement seems a bit of a shame, though.
- skykooler 7y agoEspecially as, if you're in a situation where you have to use CGI rather than a better server worker solution, you probably also don't have access to the environment to install pip packages.
- mjw1007 7y agoThe cgi module doesn't actually contain anything CGI-specific. It dates from a time when "CGI" was a sensible shorthand for "handling http requests". What's actually in the module is a rather clunky, but serviceable, system for processing html form data.
- ptx 7y agoYou can use wsgiref.handlers.CGIHandler instead, with the advantage of being able to easily move the application to some more appropriate WSGI environment later if needed.
- draegtun 7y agoYou have to keep moving forward with the times! Perl removed CGI from its core back in 2014 - https://perl5.git.perl.org/perl.git/commitdiff/e9fa5a80 https://perl5.git.perl.org/perl.git/commitdiff/e9fa5a80
- hyperion2010 7y agoThis 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?
- masklinn 7y ago> Is there no more uu encoded data in the world? The uu codec is provided by the binascii module. The uu module is a "high-level" interface for conversion between binary and uuencoded files ("-", paths, or file-like objects). Basically uuencode(1) / uudecode(1) reimplemented in python. > A programming language that throws away the past is doomed to become a passing fad. That's complete nonsense. > If the code is old who cares as long as it still works? Keeping it working is a maintenance burden. Why keep it if it's worthless?
- varelaz 7y agoAll of removed modules should go to PyPi no one is going to kill them completely. Python keeps a lot of legacy. I'm also pretty concerned with builtin robots.txt parser for example. There are much better PyPi libraries which are well maintained and have better API.
- gtirloni 7y agoIt 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.
- noname120 7y agoDupe: https://news.ycombinator.com/item?id=19971131 https://news.ycombinator.com/item?id=19971131
- imglorp 7y agoNobody 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://www.python.org/dev/peps/pep-0020/ https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...
- simonh 7y agoIt's not that it's never been possible to do things other ways in Python. The obvious way to do stuff is to use the latest module or feature. The obvious way to do string formatting is now f-strings.
- dhuramas 7y agoIn an enterprise-y environment, it's not always possible to keep upgrading to the latest. So assuming someone creates a project based on f-strings, that would be python 3.6+ only. Whereas using string.format will work across entire python 3+. Is that worth the upgrade- I'm not convinced.
- pas 7y agoYes, and? This still means that if someone gets the latest Python the f-strings should be used everywhere, because supposedly they solve every and all problems that the previous ones solved and some.
- arshbot 7y agoBut in reality, you can't ( and shouldn't ) go back and change how the rest of the legacy codebase does things just because there's a new way to do it.
- Waterluvian 7y agoI 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.
- kd5bjo 7y ago> 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.
- HelloNurse 7y agoMany ridiculous suggestions, like the whole "data encoding" group (obsolete data formats don't need maintenance) and the various modules about old file formats (ditto).
- Blackthorn 7y agoThey do need maintenance. Python updates cause code or tests to need updating due to syntax or other changes.
- diydsp 7y agoOld 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.
- truth_seeker 7y agoVery 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.