I would also prefer (2) for exactly the example given in this thread. The Windows version of curses.missing.py could raise a ModuleNotFoundError saying that curses is not available on Windows, but a developer who wants to can install PDCurses to implement the stdlib module. I don't think the few cases where an stdlib package is both missing and has a name collision with an incompatible module are enough to outweigh the benefits of being able to install a third-party package to implement a missing part of the stdlib Alex On 2016-11-28 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. - 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?).
--Guido
On Mon, Nov 28, 2016 at 8:13 AM, Paul Moore <p.f.moore@gmail.com <mailto:p.f.moore@gmail.com>> wrote:
On 28 November 2016 at 15:51, Tomas Orsava <torsava@redhat.com <mailto:torsava@redhat.com>> wrote: > 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`.
My apologies, I should have included a pointer. That is indeed the distribution I was thinking of.
> Could some Windows user please check if compiling Python with the current > reference implementation [2] of this PEP indeed generates a > `curses.missing.py <http://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.
I'll see if I can make some time to do the test. But as the change is to setup.py, and the Windows build uses Visual Studio project files to do the build, I expect that it won't generate missing.py files on Windows. In actual fact, that may be the simplest solution, to note that the build part of this change is restricted to Unix (non-Windows) platforms specifically. As there's no real concept of a "distribution version" of Python on Windows, it's probably not something that will be that important on that platform (and support for .missing.py files is there, it would just be necessary for distributors to manually create those files as needed).
Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
-- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/