[Python-ideas] PEP: Distributing a Subset of the Standard Library

[Tomas Orsava]

On 11/28/2016 05:38 PM, 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

Solution (2) is a very good alternative and can be implemented using a 
metapath hook as Steve proposed elsewhere in this thread [0].
We considered a similar metapath hook when designing the PEP, but 
decided against it, to better match the current behavior of third-party 
modules not being able to replace parts of stdlib.

Note that as Brett says elsewhere in the thread, due to caching there 
would be no extra stat() calls in the usual case. On the other hand, we 
aren't familiar with Windows, where replacing missing stdlib modules 
seems to be standard practice. Thanks for letting us know.

With a metapath hook, .missing.py files are probably overkill, and the 
hook can just look at one file (or a static compiled-in list) of 
ModuleNotFound/ImportError messages for all missing modules, as M.-A. 
Lemburg and others are suggesting. We'll just need to think about 
coordinating how the list is generated/updated: the current PEP 
implicitly allows other parties, besides Python and the distributors, to 
step in cleanly if they need to—needing to update a single list could 
lead to messy hacks.

We'll update the PEP to go with solution (2).


[0] https://mail.python.org/pipermail/python-ideas/2016-November/043837.html

Tomas Orsava


>
> On Mon, Nov 28, 2016 at 8:13 AM, Paul Moore <p.f.moore at gmail.com 
> <mailto:p.f.moore at gmail.com>> wrote:
>
>     On 28 November 2016 at 15:51, Tomas Orsava <torsava at redhat.com
>     <mailto:torsava at 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 at python.org <mailto:Python-ideas at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161129/44e7c15c/attachment-0001.html>