On 11/28/2016 03:32 PM, Paul Moore wrote:
The ``.missing.py`` extension will be added to the end of the list, and configured to be handled by ``SourceFileLoader``. Thus, if a module is not found in its proper location, the ``XYZ.missing.py`` file is found and executed, and further locations are not searched. Am I right to think that if a user had a file tkinter.missing.py in
On 28 November 2016 at 13:28, Tomas Orsava <torsava@redhat.com> wrote: the current directory, then they'd get that in preference to the stdlib tkinter? Obviously this is no different from having a tkinter.py file in that directory, so it's not like this is a major problem, but it might be worth pointing out this minor incompatibility.
Correct, both tkinter.py and tkinter.missing.py in the current directory will take precedence. I will note this in the backwards compatibility section.
Also, and possibly more of an issue, use of the ".missing.py" file will mean that a user can't provide their own implementation of the module later on sys.path. I don'rt know if this is a significant issue on Unix platforms. On Windows, there is a 3rd party implementation of the curses module which (as I understand it) can be user installed. If Python included a curses.missing.py, that would no longer work.
Certainly these are only minor points, but worth considering.
I believe I may have found the Windows curses implementation, it's called PDCurses [0], and this website [1] appears to be distributing it under the name `curses`. 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. [0] http://pdcurses.sourceforge.net/ [1] http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses [2] https://www.python.org/dev/peps/pep-0534/#reference-implementation Thank you for the feedback!