Anthony Sottile <asott...@umich.edu> added the comment:
I think nearly all of the use cases in the packages are valid (except module-layout) -- or at least if this feature were removed without having a startup-time site-packages code execution feature there would be no possible replacement. I'll elaborate a little more on the titles I've chosen: * backport: provide features that are not available to that python version, but were ratified peps in later versions. These necessarily must happen at startup as to affect the application being used * demo: these are fine to ignore, the two packages that were classified here were merely demoing how to use `.pth` files can be packaged with setuptools * coverage: almost all of these were "automatically instrument coverage in subprocesses under test", basically the need to enable coverage tracing in subprocesses triggered by the application under test. It is not possible to do this in any other way than an initialization hook in the interpreter (or monkeypatching the subprocess module, which I'd argue is significantly worse than what this is doing) * debugging: these provide additional introspection tools to analyze an application, these also need to be interpreter level as you cannot customize code outside of your control but may need to debug such code. * except-hook: these also seem necessary as well, from the few I looked into more detail they seemed to be setting hooks such that $foreign-application could be used within another framework -- looking very similar to ubuntu's `sitecustomize.py` which sends traces to apport on crash (bug reporting for python-based packages). If you had ownership of this application sure you could add an except hook, but these seem t be for cases where you do not control the application * monkeypatch: I don't think we should be so swift to banish this category, sure the name is scary but there were many legitimate cases here. Many of these were to patch limitations in packages outside of control (dead, no longer accepting patches, not willing to support other platforms, etc.). the patches necessarily happen at startup because there's no other place to influence the code of these third party tools. Don't get me wrong, monkeypatching is usually bad, but I don't think there would be an alternative to how these tools function if this feature were removed. * import-hook: I also don't see an easy way to work around these, most of these added alternate filetypes that python could import, but you need *something* to make importing work in the first place > Basically everyone wants to remove the second one, but we can't do that until > there is replacement functionality for its legitimate use cases. Without a poll I don't think assuming a majority is fair ;) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33944> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
