On Nov 28, 2016 8:38 AM, "Guido van Rossum" <guido@python.org> wrote:
Overall I think this is a good idea. I have one hit:
It seems that there are two possible strategies for searching the
.missing.py file:
1. (Currently in the PEP) search it at the same time as the .py file when
- Pro: prevents confusion when the user accidentally has their own matching file later in sys.path. - Con: prevents the user from installing a matching file intentionally (e.g. a 3rd party version).
2. After exhausting sys.path, search it again just for .missing.py files (or perhaps remember the location of the .missing.py file during the first search but don't act immediately on it -- this has the same effect). - Pro: allows user to install their own version. - Con: if the user has a matching file by accident, that file will be imported, causing more confusion.
I personally would weigh these so as to prefer (2). The option of installing your own version when the standard version doesn't exist seems reasonable; there may be reasons that you can't or don't want to install
walking along sys.path. the distribution's version. I don't worry much about the danger of accidental name conflicts (have you ever seen this?). I was going to make a similar comment, because it seems to me that it could make sense for a redistributor to want to move some bits of the stdlib into wheels, and this is most conveniently handled by letting bits of the stdlib live in site-packages. Also note that in Guido's option 2, we only incur the extra fstat calls if the import would otherwise fail. In option 1, there are extra fstat calls (and thus disk seeks etc.) adding some overhead to every import. -n