5 ms·

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing tricky about it. Why delete it? It's good at what it does. Subprocess equivalents are a lot more effort to write, even if you can eventually get to the same result. Uu is old, yes. But it's not broken either. Folks do still uuencode things from time to time. Why delete it? Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console. I hate that the answer is "Use something on Pypi instead", because that increases my dependency surface and adds no value for me. Why delete working, stable code?

qbasic_forever 5y ago
Nothing is stopping those libraries from being in a new 'legacy internet' package that motivated folks can maintain on pypi.
- nrclark 5y ago
  You're right, nothing is stopping anybody from putting these modules on Pypi. If somebody's already using Pypi dependencies, then another is no big deal. But there's a really big jump from "This tool is self-contained" to "This tool needs X from pypi". It ripples into deployment, source-control, everything. I try very hard to make tools that don't need anything except for Python's stdlib. That's based on a perception of trust: that the stdlib will be supported, and represents Python's only stable dependency. Once the team starts to erode that trust, Python's compatibility story will start to break.
  - qbasic_forever 5y ago
    cgi, nntp, telnet, etc. are old and obsolete. And not just in the 5 years out of fashion/not the trendy new thing--these things are decades out of date and have major or glaring security issues, etc. If you're publishing brand new code in 2022 that still depends on python's built-in cgi support, etc. you have far greater problems than having to pull in a third party dependency now. Python changes in breaking ways--just look at the python 2 to 3 change. You will have to learn to deal with it. There is no explicit guarantee that python will continue to work in exactly the way it has always worked for you forever.
    - hannob 5y ago
      what's the major glaring security issue of cgi that you would consider a dealbreaker for a simple http-based service? (this is an honest question, because when I saw this list I actually have a python script running on an apache web server that is using the cgi module to access post variables, and I never saw any need to change that, as any other "more modern" solution would be much more bothersome to configure and maintain.)
      - qbasic_forever 5y ago
        What is your auth and session story? Because I doubt you're implementing OIDC, JWT, etc. in a cgi script vs. relying on a modern framework that does all the work for you. HTTP basic auth? Well, there's your security issue right there. So presumably you are happy to have a web accessible endpoint running on your server that will pop a new process and start executing a local script (which might be reading/writing files, other services, etc.) without checking any permissions, enforcing any cross site scripting or CSRF protections, etc. It might be fine for the most trivial appplication. For anything that actually changes state or has side effects, I would be very concerned and it would never pass a serious security review.
        c0l0 5y ago
        HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".
        qbasic_forever 5y ago
        It's a massive footgun and no sane security review would let a production service pass with HTTP basic auth. You're one misconfigured TLS proxy away from major security breaches and issues.
        Spivak 5y ago
        Uhhh what? Do you think either * basic auth only exists at the proxy layer to protect apps with no auth. * commonly deployed auth systems are secure without TLS? because both are false. Check out the Rails Devise support for HTTP basic auth which is perfectly secure. And check that basically zero auth systems in the wild use PAKE and so are entirely dependent on TLS to secure the password transmission in flight.
  - munch117 5y ago
    If you want to step up and be the maintainer of one or more of these modules in the standard library, I'm pretty sure you would be welcomed. PEP 594 is basically just a formalisation of the fact that no one has volunteered to do this yet.
    - themadsens 5y ago
      Arguing that opponents to removal "can just step up as maintainers" are completely bogus. As mentioned elsewhere, this is more about eroding trust in stdlib as a stable baseline. This is just the kind of thing that will teach people to not trust Python as a stable foundation. Also. If maintenance of aging modules becomes tiresome, maybe it is a strong hint to keep backwards compatibility in Python proper.
      - munch117 5y ago
        Not at all bogus. If "eroding trust in stdlib as a stable baseline" is an important issue to you, then you can do something about it by helping provide the resources that allows old modules to be kept. Core language backwards compatibility is a non-issue. Approximately zero percent of maintenance costs go towards that.
        qbasic_forever 5y ago
        Not to mention python has an entirely open proposal process where anyone at any point could have commented and expressed a desire to keep these libraries in the standard library. It seems after this entire process not enough people need them in the standard library.
        nitrogen 5y ago
        > It seems after this entire process not enough people need them in the standard library. I'm reminded of the Hitchhiker's Guide to the Galaxy: "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard."
mjw1007 5y ago
The cgi module didn't actually contain the Python standard library's CGI support. That's in wsgiref.handlers.CGIHandler, and isn't going away. What the cgi module did contain was some occasionally-useful support for working with HTML forms. As far as I can tell they're throwing that away for no good reason.
- a-dub 5y ago
  isn't that basically the bulk of the CGI standard? parsing environment variables and stdin for http get/post data? what else is left? emitting mime type headers and such and two newlines?
moltke 5y ago
Meh. CGI was one of the easier to consume interfaces that is really not hard to rebuild from scratch. I suppose it makes sense that python has (or had I guess) a library for it but it's really not necessary. Enough of the primitives are there. Those that need it could easily write a shim. It does make you wonder why it was removed though. I can't imagine it was difficult to maintain.
ciupicri 5y ago
For uuencode migrate to a2b_uu and b2a_uu from the binascii standard module. [a2b_uu]: https://docs.python.org/3/library/binascii.html#binascii.a2b_uu https://docs.python.org/3/library/binascii.html#binascii.a2b... [b2a_uu]: https://docs.python.org/3/library/binascii.html#binascii.b2a_uu https://docs.python.org/3/library/binascii.html#binascii.b2a...
popularonion 5y ago
> “Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console.” The kind of person behind a decision like this has never heard of QEMU and won’t care even if you tell them. “Why don’t you use Docker or k8s?”
bariumbitmap 5y ago
Indeed, the uu module is a short Python wrapper around binascii. It's only 206 lines, much of which is comments or docstrings: https://github.com/python/cpython/blob/a5b7678a67ac99edd50822827b772e7d9afc8e64/Lib/uu.py https://github.com/python/cpython/blob/a5b7678a67ac99edd5082... It has three functions: one to encode, one to decode, and one to show usage information and handle arguments. It's only had 3 commits since 2010. There just isn't much to maintain.

qbasic_forever 5y ago

Nothing is stopping those libraries from being in a new 'legacy internet' package that motivated folks can maintain on pypi.

nrclark 5y ago
You're right, nothing is stopping anybody from putting these modules on Pypi. If somebody's already using Pypi dependencies, then another is no big deal. But there's a really big jump from "This tool is self-contained" to "This tool needs X from pypi". It ripples into deployment, source-control, everything. I try very hard to make tools that don't need anything except for Python's stdlib. That's based on a perception of trust: that the stdlib will be supported, and represents Python's only stable dependency. Once the team starts to erode that trust, Python's compatibility story will start to break.
- qbasic_forever 5y ago
  cgi, nntp, telnet, etc. are old and obsolete. And not just in the 5 years out of fashion/not the trendy new thing--these things are decades out of date and have major or glaring security issues, etc. If you're publishing brand new code in 2022 that still depends on python's built-in cgi support, etc. you have far greater problems than having to pull in a third party dependency now. Python changes in breaking ways--just look at the python 2 to 3 change. You will have to learn to deal with it. There is no explicit guarantee that python will continue to work in exactly the way it has always worked for you forever.
  - hannob 5y ago
    what's the major glaring security issue of cgi that you would consider a dealbreaker for a simple http-based service? (this is an honest question, because when I saw this list I actually have a python script running on an apache web server that is using the cgi module to access post variables, and I never saw any need to change that, as any other "more modern" solution would be much more bothersome to configure and maintain.)
    - qbasic_forever 5y ago
      What is your auth and session story? Because I doubt you're implementing OIDC, JWT, etc. in a cgi script vs. relying on a modern framework that does all the work for you. HTTP basic auth? Well, there's your security issue right there. So presumably you are happy to have a web accessible endpoint running on your server that will pop a new process and start executing a local script (which might be reading/writing files, other services, etc.) without checking any permissions, enforcing any cross site scripting or CSRF protections, etc. It might be fine for the most trivial appplication. For anything that actually changes state or has side effects, I would be very concerned and it would never pass a serious security review.
      - c0l0 5y ago
        HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".
        qbasic_forever 5y ago
        It's a massive footgun and no sane security review would let a production service pass with HTTP basic auth. You're one misconfigured TLS proxy away from major security breaches and issues.
        Spivak 5y ago
        Uhhh what? Do you think either * basic auth only exists at the proxy layer to protect apps with no auth. * commonly deployed auth systems are secure without TLS? because both are false. Check out the Rails Devise support for HTTP basic auth which is perfectly secure. And check that basically zero auth systems in the wild use PAKE and so are entirely dependent on TLS to secure the password transmission in flight.
- munch117 5y ago
  If you want to step up and be the maintainer of one or more of these modules in the standard library, I'm pretty sure you would be welcomed. PEP 594 is basically just a formalisation of the fact that no one has volunteered to do this yet.
  - themadsens 5y ago
    Arguing that opponents to removal "can just step up as maintainers" are completely bogus. As mentioned elsewhere, this is more about eroding trust in stdlib as a stable baseline. This is just the kind of thing that will teach people to not trust Python as a stable foundation. Also. If maintenance of aging modules becomes tiresome, maybe it is a strong hint to keep backwards compatibility in Python proper.
    - munch117 5y ago
      Not at all bogus. If "eroding trust in stdlib as a stable baseline" is an important issue to you, then you can do something about it by helping provide the resources that allows old modules to be kept. Core language backwards compatibility is a non-issue. Approximately zero percent of maintenance costs go towards that.
      - qbasic_forever 5y ago
        Not to mention python has an entirely open proposal process where anyone at any point could have commented and expressed a desire to keep these libraries in the standard library. It seems after this entire process not enough people need them in the standard library.
        nitrogen 5y ago
        > It seems after this entire process not enough people need them in the standard library. I'm reminded of the Hitchhiker's Guide to the Galaxy: "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard."

mjw1007 5y ago

The cgi module didn't actually contain the Python standard library's CGI support. That's in wsgiref.handlers.CGIHandler, and isn't going away. What the cgi module did contain was some occasionally-useful support for working with HTML forms. As far as I can tell they're throwing that away for no good reason.

a-dub 5y ago
isn't that basically the bulk of the CGI standard? parsing environment variables and stdin for http get/post data? what else is left? emitting mime type headers and such and two newlines?

moltke 5y ago

Meh. CGI was one of the easier to consume interfaces that is really not hard to rebuild from scratch. I suppose it makes sense that python has (or had I guess) a library for it but it's really not necessary. Enough of the primitives are there. Those that need it could easily write a shim. It does make you wonder why it was removed though. I can't imagine it was difficult to maintain.

ciupicri 5y ago

For uuencode migrate to a2b_uu and b2a_uu from the binascii standard module. [a2b_uu]: https://docs.python.org/3/library/binascii.html#binascii.a2b_uu https://docs.python.org/3/library/binascii.html#binascii.a2b... [b2a_uu]: https://docs.python.org/3/library/binascii.html#binascii.b2a_uu https://docs.python.org/3/library/binascii.html#binascii.b2a...

popularonion 5y ago

> “Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console.” The kind of person behind a decision like this has never heard of QEMU and won’t care even if you tell them. “Why don’t you use Docker or k8s?”

bariumbitmap 5y ago

Indeed, the uu module is a short Python wrapper around binascii. It's only 206 lines, much of which is comments or docstrings: https://github.com/python/cpython/blob/a5b7678a67ac99edd50822827b772e7d9afc8e64/Lib/uu.py https://github.com/python/cpython/blob/a5b7678a67ac99edd5082... It has three functions: one to encode, one to decode, and one to show usage information and handle arguments. It's only had 3 commits since 2010. There just isn't much to maintain.