On 24 August 2017 at 05:04, John Torakis <john.tora...@gmail.com> wrote: > Dark times... > > So is it a "case closed", or is there any improvement that will make it > worth it to be an stdlib module?
Not really, as even aside from the security concerns, there are simply too many ways that it can fail that are outside of our control, but would potentially lead to folks filing bug reports against CPython without realising that the problem actually lies somewhere else (e.g. with their network configuration). For a third party module, that's not a problem: - folks have to find out httpimport exists - folks have to decide "I want this" - folks have to explicitly install & enable it - folks still get to keep all the very shiny pieces when it breaks unexpectedly, but they also already know where to go for help :) Being a third party utility means you can also update it on your own timeline, rather than being limited to the standard library's relatively slow update and rollout cycles. >From a compatibility point of view, we also *like* having sophisticated import system plugins like httpimport out in the wild, as it means: - it actually makes sense to define & maintain the import plugin APIs that make it possible - there's additional integration testing of those APIs happening beyond our own test suite Putting away my import system co-maintainer hat and donning my commercial redistributor hat: it already bothers some of our (and our customers') security folks that we ship package installation tools that access unfiltered third party package repositories by default (e.g. pip defaulting to querying PyPI). As a result, I'm pretty sure that even if upstream said "httpimport is in the Python standard library now!", we'd get explicit requests asking us to take it out of our redistributed version and make it at most an optional install (similar to what we do with IDLE and Tcl/Tk support in general). Cheers, Nick. P.S. As a potentially useful point of reference: "it's hard to debug when it breaks" is the main reason we resisted adding native lazy import support for so long, and that's just a matter of moving import errors away from the import statement and instead raising them as a side effect of an attribute access. It's also why we moved reload() *out* of the builtins in the move to Python 3: while module reloading is a fully supported operation, it also has a lot of subtleties that make it easy to get wrong. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
