On 11/28/2016 11:38 AM, Guido van Rossum 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 walking along sys.path.
  - 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.

The Windows distribution. for instance, could have a mod.missing.py file for every non-Windows, unix-only module.  This would cut down on 'Why did this import fail?' questions on SO and python-list.  And without breaking anything. Even for non-beginners, it would save having to look up whether the an import failure is inherent on the platform or due to a typo.

  - 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 the distribution's version. I don't worry much about the danger
of accidental name conflicts (have you ever seen this?).

The accidental conflict reports I have seen were due to scripts in as in the same directory as the program, rather than modules in site-packages.