On Nov 8, 2019, at 07:50, Steve Barnes <gadgetst...@live.co.uk> wrote:, > > > I hope that his hasn’t been discussed to death in the past but I quite often > encounter cases where developers have unwittingly created a file or directory > that has a name clash with either a system import or a pip installed library > import.
There was a somewhat similar thread a few months back about creating a std package that all of the stdlib modules could be imported from. So if you want to make sure you’re getting the system struct library as opposed to a local one, you could `from std import struct`. And, while I don’t think it was raised at the time, the idea could be extended to have packages for site (although the obvious name is already taken) and local, or maybe even allow you to add custom names to custom entries in sys.path. You probably want to find and read that old thread. IIRC, the idea foundered on bikeshedding issues, like: Are std.struct and struct the same module despite being imported differently? If so, what’s the qualified name of that module (and if that’s not just struct, is that a backward compatibility problem), and how does that work with sys.modules and the import system in general? If not, do we have to deprecate importing bare struct? What exactly is in std? Everything installed with the system? Everything that happens to be in a particular directory (plus statically linked in plus frozen into the bootstrap)? Just the stuff that’s available on all Python 3.9 implementations and platforms? Just what’s documented in the library reference? (Is there a platform or cpython or windows or whatever package for the stuff that’s part of CPython 3.9 for Windows but not part of Python 3.9? What about the stackless package that’s built into Stackless and PyPy? What about packages that are standard but optional, like curses, which is theoretically available on every platform but in practice Windows users never have it and only CPython and PyPy include it?) What happens with custom builds of Python, or custom embedding apps, where parts of the stdlib and third-party libs might both be statically linked into the binary, bootstrapped into the importer, and/or stored together in a python39.zip? (You wouldn’t want to build something that works, then package it for distribution with py2app or pyInstaller and have it stop working because stuff that used to be local is now system, and I don’t think you want py2app to have to edit code on the fly while packaging it to fix that, but maybe having it set up a list of packages in a single place would work or something?) There would also be some new questions from extending the idea. For example, are the user and system-wide site packages treated differently or merged together? What about (non-isolated) virtual environment vs. underlying installation? If someone ever updates Jython or Iron to 3.x, what namespace do Java or .NET packages live in? While we’re at it, this might also be an opportunity to solve the problem where running script.py means the same code is available as two separate modules script and __main__, but I’m not sure. Anyway, I think a big part of the problem last time around was that the OP didn’t have a clear idea of what the std package was trying to accomplish, so the answers weren’t obvious, while you seem to have a clear idea of exactly what you want to solve, and are interested in std specifically to solve that problem, so maybe it would be different. There’s a good chance if you went back and read over that thread, you could preemptively answer all of those questions and turn this into a proposal that covers everything but the implementation details (with maybe a few narrow open questions).
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3B7NHB7Z7F7B2R5ASQLEJ7NWWYZOFFPC/ Code of Conduct: http://python.org/psf/codeofconduct/
