On Mon, Nov 28, 2016, at 10:51, Tomas Orsava wrote:
Could some Windows user please check if compiling Python with the current reference implementation [2] of this PEP indeed generates a `curses.missing.py` file among the stdlib files? If so, we might consider skipping the generation of the .missing.py file for the curses module on Windows.
"Skip it for curses on Windows" doesn't seem like an acceptable solution, because tomorrow there could be another module, on another platform, that needs a similar fix. I think it'd be better to fix the logic. Searching the whole path for whatever.py before searching for whatever.missing.py makes sense to me and I'm not sure why this isn't the proposal. Honestly, though, I'm not sure of the need for the PEP in general. "However, there is as of yet no standardized way of dealing with importing a missing standard library module." is simply not true. The standardized way of dealing with it is that the import statement will raise an ImportError exception. Why exactly is that not good enough? A distribution could, for example, include an excepthook in site.py that prints an informative error message when an ImportError is unhandled for a list of modules that it knows about. Or they could modify the *default* excepthook in the interpreter itself.