4 ms·

You think that's the only module they dropped? They took away cgi… which I was of course using. And crypt. They don't care about breaking things. People woul

by guappa 3y ago

You think that's the only module they dropped? They took away cgi… which I was of course using. And crypt. They don't care about breaking things. People would not migrate to python4 so they just break everything in python3 :D

eesmith 3y ago
The cgi module is still in 3.12. It will be removed in 3.13, which is planned for release on 2024-10-01, so not yet dropped. FWIW, the Python developers have wanted to drop the cgi module for over 20 years. It has no maintainer. Depending on your needs, you might consider: 1) versioning and maintaining your own copy of cgi.py; 2) use something like https://pypi.org/project/legacy-cgi/ https://pypi.org/project/legacy-cgi/ (I have not vetted it) which is a forked copy of cgi and cgitb; or 3) use the CGI capabilities of wsgiref (I used it for one CGI project to allow a future transition away from CGI). As for "crypt" - wow! I haven't seen anyone use that since the 1990s! Again, the code is short, and easy to vendor, except for the _crypt extension module. For that, you might be able to use ctypes, like this: >>> from ctypes.util import find_library >>> find_library("c") '/usr/lib/libc.dylib' >>> from ctypes import cdll >>> libc = cdll.LoadLibrary(find_library("c")) >>> import ctypes >>> libc.crypt.argtypes = [ctypes.c_char_p, ctypes.c_char_p] >>> libc.crypt.restype = ctypes.c_char_p >>> libc.crypt(b"toomanysecrets", b"az") b'azi4LBG1VJohQ' Here is what Python's own _crypt does: >>> import _crypt >>> _crypt.crypt("toomanysecrets", "az") 'azi4LBG1VJohQ'
- fulafel 3y ago
  What does it mean to say "it has no maintainer" about code in the Python standard library? In most other projects the standard library is jointly maintained by the core team. In version history the cgi module seemed to receive small fixes couple of times a year from different people.
  - eesmith 3y ago
    "Has no maintainer" means there is no one who has said they have the expertise to be able to render final judgment on a bug report or other issue. "If no active maintainer is listed for a given module, then questionable changes should be discussed on the Core Development Discourse category, while any other issues can and should be decided by any committer." - https://devguide.python.org/core-developers/experts/index.html https://devguide.python.org/core-developers/experts/index.ht... In practice, what that means is if there is a bug report, like https://github.com/python/cpython/issues/71964 https://github.com/python/cpython/issues/71964 from 2016, then the fix may languish for years as no one in the core team is able to resolve it. You can see several people reported the bug, along with a comment from 2022 that "The cgi module is now deprecated following the acceptance of PEP 594" so will not be fixed. The fixes I saw likely fall into the un-questionable changes that can be decided by any committer.
- guappa 3y ago
  > FWIW, the Python developers have wanted to drop the cgi module for over 20 years. It has no maintainer. It works. Does it need a maintainer? The point isn't how to replace them. The point is that I have stuff that works and has been working for several years and will stop working.
  - eesmith 3y ago
    Then Python is not the language for you, and never has been. The Python core developers have had a practice of removing standard library packages for over 30 years, including packages that - like cgi.py - worked. For example, modules removed with Python 2.0 included cmp, cmpcache, dircmp, dump, find, grep, packmail, poly, stdwin, util, whatsound, and zmod. Python 2.4 removed mpz, rotor, and xreadlines - no more Enigma machine emulation for you, and I had to change my code because I used xreadlines. Python 3.0 removed even more modules: cl, md5, sha, rfc822, and more. Plus it did some library reorganization. Ever use the "parser" module? I did. It was removed in 3.10 because of the switch to the PEG parser. PEP 594 re-affirms the reasoning behind the long-given practice removing old packages. There are language communities with a stronger commitment to not breaking old code. COBOL is fantastically backwards compatible, for an obvious example. I urge you to consider the options I gave. The functionality you want can be done using the standard library without that much effort.

by guappa 3y ago

eesmith 3y ago

The cgi module is still in 3.12. It will be removed in 3.13, which is planned for release on 2024-10-01, so not yet dropped. FWIW, the Python developers have wanted to drop the cgi module for over 20 years. It has no maintainer. Depending on your needs, you might consider: 1) versioning and maintaining your own copy of cgi.py; 2) use something like https://pypi.org/project/legacy-cgi/ https://pypi.org/project/legacy-cgi/ (I have not vetted it) which is a forked copy of cgi and cgitb; or 3) use the CGI capabilities of wsgiref (I used it for one CGI project to allow a future transition away from CGI). As for "crypt" - wow! I haven't seen anyone use that since the 1990s! Again, the code is short, and easy to vendor, except for the _crypt extension module. For that, you might be able to use ctypes, like this: >>> from ctypes.util import find_library >>> find_library("c") '/usr/lib/libc.dylib' >>> from ctypes import cdll >>> libc = cdll.LoadLibrary(find_library("c")) >>> import ctypes >>> libc.crypt.argtypes = [ctypes.c_char_p, ctypes.c_char_p] >>> libc.crypt.restype = ctypes.c_char_p >>> libc.crypt(b"toomanysecrets", b"az") b'azi4LBG1VJohQ' Here is what Python's own _crypt does: >>> import _crypt >>> _crypt.crypt("toomanysecrets", "az") 'azi4LBG1VJohQ'

fulafel 3y ago
What does it mean to say "it has no maintainer" about code in the Python standard library? In most other projects the standard library is jointly maintained by the core team. In version history the cgi module seemed to receive small fixes couple of times a year from different people.
- eesmith 3y ago
  "Has no maintainer" means there is no one who has said they have the expertise to be able to render final judgment on a bug report or other issue. "If no active maintainer is listed for a given module, then questionable changes should be discussed on the Core Development Discourse category, while any other issues can and should be decided by any committer." - https://devguide.python.org/core-developers/experts/index.html https://devguide.python.org/core-developers/experts/index.ht... In practice, what that means is if there is a bug report, like https://github.com/python/cpython/issues/71964 https://github.com/python/cpython/issues/71964 from 2016, then the fix may languish for years as no one in the core team is able to resolve it. You can see several people reported the bug, along with a comment from 2022 that "The cgi module is now deprecated following the acceptance of PEP 594" so will not be fixed. The fixes I saw likely fall into the un-questionable changes that can be decided by any committer.
guappa 3y ago
> FWIW, the Python developers have wanted to drop the cgi module for over 20 years. It has no maintainer. It works. Does it need a maintainer? The point isn't how to replace them. The point is that I have stuff that works and has been working for several years and will stop working.
- eesmith 3y ago
  Then Python is not the language for you, and never has been. The Python core developers have had a practice of removing standard library packages for over 30 years, including packages that - like cgi.py - worked. For example, modules removed with Python 2.0 included cmp, cmpcache, dircmp, dump, find, grep, packmail, poly, stdwin, util, whatsound, and zmod. Python 2.4 removed mpz, rotor, and xreadlines - no more Enigma machine emulation for you, and I had to change my code because I used xreadlines. Python 3.0 removed even more modules: cl, md5, sha, rfc822, and more. Plus it did some library reorganization. Ever use the "parser" module? I did. It was removed in 3.10 because of the switch to the PEG parser. PEP 594 re-affirms the reasoning behind the long-given practice removing old packages. There are language communities with a stronger commitment to not breaking old code. COBOL is fantastically backwards compatible, for an obvious example. I urge you to consider the options I gave. The functionality you want can be done using the standard library without that much effort.