The Substitute entries are there to note if there are other standard library packages that can cover the functionality, not if the package won’t see a release on PyPI or doesn’t already have alternatives there. I’m not sure what argument you are making with that.
I can see your point there; I think Christian was simply not aware that AIFF is still widely used. Personally, I see that as an argument to drop WAV support too!
The module is pretty much unmaintained and have not seen any improvements, e.g. OSSv4 support. Almost all commits in the last 8 years are related to project wide code cleanups. Serhiy and Victor have spent time on the module although they are not FreeBSD users.
CPython contains no bindings for Windows and ALSA. IMHO OSS is not special enough to have it in the core.
It would be more beneficial for everybody if the module would be picked up and maintained by the FreeBSD community. It would free resources for CPython devs and get actual users a better experience.
Thanks for you feedback, but it’s slightly off topic. Could you please look for an existing bug on our bug tracker for de-deprecation of the optparse module and creaet a new one in case there is none? Thanks
I’d like to suggest one principle that makes particular modules valuable in the standard library.
A lot of the value of a large standard library is in making it possible to write programs without any dependencies from PyPI. Once you’ve set up requirements.txt and a virtualenv and all, adding another dependency is pretty cheap, but the first one is expensive.
So modules are particularly valuable in the standard library if they’re likely to be used in small scripts or ‘glue’ code, or when you’re using a bit of Python in a project that’s mostly in another language.
I don’t think it has been a great success, but subprocess doesn’t yet have a replacement for what it does, and its main use is when you find your shell script has grown too big and you want to start to rewrite it in Python.
That’s exactly the situation where you don’t want to have to set up a virtualenv.
Note that it doesn’t really have anything to do with the CGI protocol (so the bit of the PEP that talks about CGI being inefficient is a little out of place).
Rather it’s for dealing with the way browsers represent form data.
There’s no alternative for that in the standard library, and it’s very much the sort of thing that you sometimes want to do in a small standalone CGI or WSGI script. Certainly I have scripts like that using it, and giving each one a virtualenv would be a pain.
It doesn’t cause you harm by them being included in the stdlib, but it does harm/cost us core developers who have to keep them functioning. And nothing, no matter how small, is free to maintain. Even people filing feature requests that won’t be addressed take time to close (and remember we have over 1,000 open PRs right now so there’s a scale issue we are dealing with). Code is simply just not free in terms of time and we already have so much other code as a team to keep functioning that we can’t keep every module that we have accumulated running to a standard we are happy with, so we need to cut somewhere.
So while we understand that Python’s popularity guarantees that every module in the stdlib is used by someone, this list is trying to pull out the extent of what modules we can reasonably ask the community to take over maintenance for instead of shouldering us core devs with the burden forever.
When deciding on these modules, did anyone look at how much time they actually take to maintain, in terms of # of issues either filed or closed?
My experience is that, while not widely used, it’s still valuable to have a few of these batteries included - it may only be on occasion that they’re ultimately useful, but to those of us that occasionally use them, they’re invaluable.
Heck - if the existing things (e.g. cgi) are currently so terrible that they need to be tossed out and re-written from scratch, rather than just say, “Let’s get rid of these” Why not say instead, “This is terrible and we’d love to keep it around, but it needs a complete overhaul. To help out with the overhaul, go . Otherwise, this module will be deprecated & removed.”
That way it gives people who have an investment the opportunity to put their money/time where their mouth is - to spend some time actually fixing the problems.
Isn’t this already (part of) the message this PEP sends? A draft PEP is posted so people can discuss whether modifications are needed, and guaranteeing a module is important and well-maintained is certainly one of the valid arguments to keep it from being included in the PEP.
I think it should be understood as a module giving access to the OS-provided crypt(3), rather than a general purpose password hashing utility (it’s documented under “Unix specific services” rather than “Cryptographic Services”, after all).
Python includes wrappers for most traditional libc functions, and crypt is still sometimes useful because it can give the same answer as other software (probably not written in Python) running on the same machine.
It would probably be worth updating the module’s documentation to make it clearer that this isn’t what you want if you’re not trying to interoperate with some existing password store.
I’m not thinking of the system password file, rather services like Dovecot or Apache.
Also, if you’re running a service that’s been around for many years, the usual way to handle an upgrade to the hashing format is to re-hash passwords when users log in. So if you started out using one of the crypt formats, you may still need it. (But this doesn’t sound like the sort of project that would have great difficulty adding a dependency from PyPI.)