81–90 of 95 posts
It might be better to upload all the modules to PyPI as third party repos. Maybe hand it off to some third party maintainers. This way if import cgi fails then you can at least pip install cgi to fix that
This code is all open source, literally anyone could step up and do it themselves if they had the motivation.
I feel that every release, the python team should do some soul searching and pick 5 modules to downgrade to external package(pypi) status, then pick 5 deserving external packages and elevate them to base status. This would, for one, add a bit of churn to the standard library leading to a more healthy ecosystem. And two, give everyone a target to complain about, I mean, people are going to complain about something, mi…
The SC have also said this is a one time event and they won't accept a similar PEP in the future, modules in the future most be handled on a case by case basis and the preferred outcome will not be to remove them.
In Java for instance, StringBuffer and StringBuilder offer a very similar interface but one offers locking. Nowadays, most locking concerns are left to the caller, not the called. HashTable/HashMap are another example... The nice thing is, old libraries "just work". Java is trying to hide older parts of the API with Modules, and it remains to be seen whether or not this solution will take off and it will be adopted into other languages.
Earlier quoted context omitted.
WebOb uses cgi for parsing multipart uploads/forms... It's not obsolete, and it is heavily used, it's working software that works well. Ripping it out just means now there will be N copies floating around that will all need to get patched/fixed instead of just a single version included with Python.
Well apparently it's not heavily enough used that any of its current users were motivated enough to discuss the PEP and make a strong case for keeping it in the standard library. The discussion was open for _three years_ and had hundreds of comments: https://discuss.python.org/t/pep-594-removing-dead-batteries... The outcome is that there isn't enough usage to merit this being in the standard library.
Is my comment. It's the 6th comment down. Clearly I didn't make a strong enough case, but I certainly did advocate for it and mention that it is in use.
Earlier quoted context omitted.
HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".
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.
* 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.
Earlier quoted context omitted.
I suspect there's very little overlap between users of development software and participants in the bureaucracy that designs the software. The requisite personality types are very different.
If you're developing software that depends on a python standard library it is on you to subscribe to the relevant mailing lists so you can be notified of security issues, deprecations, changes, etc. There is not bureaucracy here to be aware of what's happening, or even comment on the changes.
Earlier quoted context omitted.
If you're developing software that depends on a python standard library it is on you to subscribe to the relevant mailing lists so you can be notified of security issues, deprecations, changes, etc. There is not bureaucracy here to be aware of what's happening, or even comment on the changes.
Years ago I used to do that. But nowadays I use so much external stuff it's impossible. So I'm actually immensely grateful to the Python team for including so much in the Standard Library and maintaining it for decades - because for me, at least until now, it's been that one part where I could relax a bit about and be confident that competent people will take care of everything and I won't need to spend much time ana…
Earlier quoted context omitted.
HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".
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.
Earlier quoted context omitted.
FWIW, CPython officially follows Microsoft’s support schedule on Windows systems, so versions ≥ 3.9 won’t even install on Windows 7. (Some reasonable people like it and some don’t, but this has been the official stance for a long time.) As for MSI, I’m torn: it is the most widely-supported and reliable packaging approach for Windows and, at the same time, a 20-year-old undocumented dumpster fire of an archive format…
Windows 7 is the best version of Windows Microsoft ever made, and I won't give it up until I have absolutely no choice. I'm already disappointed that I can't get Python 3.9 - I don't understand why they have to actively bar you from installing it rather than just telling you to use it at your own risk.
Also, I agree that 7 was a fine OS, but it is more than two years in the grave... you cannot expect continued support for it. It is sad, but a statement of fact.
I don't understand the motivation to remove MSI support. The document says: > Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a new deployment model First, MSI has better OS support than AppX, second, many users are still using Windows 7 and won't be able to use AppX. MSI is not some 30-years old deprecated standard.
If I were to replace my msilib-based installer, I would migrate to Wix# [1], a fantastic high-level wrapper for WiX that lets you express your installer in a few lines of C# (and then generates the thousands of lines of XML that WiX needs, but you don't need to touch it). I wouldn't have used msilib if I had known about Wix# at the time.