Re: [Python-Dev] PEP 451 update
On 2 November 2013 08:44, Eric Snow wrote: > On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote: >> Thanks for the clarification. It all SGTM. > > I've updated the PEP and the reference implementation. While I was saying loader when I should have been saying finder, Eric correctly divined my intent :) > If I've missed > anything please let me know. There is only one thing I thought of > that I'd like to get an opinion on: > > In the Finders section, the PEP specifies returning None (or using a > different loader) when the found loader does not support loading into > an existing module (e.g during reload). An alternative to returning > None would be for the finder to raise ImportError with a message like > "the loader does not support reloading the module". This may actually > be a better approach since "could not find a loader" and "the found > loader won't work" are different situations that a single return value > (None) may not sufficiently represent. Throwing ImportError for "can load, but cannot load into that target module" sounds good to me. We should also be explicit that throwing an exception from find_spec *stops* the search (unlike returning None). > Other than that, I'm not aware of any blockers for the PEP. The one slight quibble I have with the PEP update is the wording regarding the "existing" parameter. I think runpy should pass the new parameter as well when calling find_spec, but in that case it *won't* be an existing copy of the named module, it will be sys.modules["__main__"]. So we shouldn't set an expectation that the existing module passed in will necessarily be a previous copy of the module being loaded, it's just an indication to the finder that the target namespace for execution will be a pre-existing module rather than a new one. For the same reason, I also have a mild preference for "target" (or the more explicit "load_target") as the name, although I won't object if you and Brett prefer "existing". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 update
On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan wrote: > On 2 November 2013 08:44, Eric Snow wrote: > > On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote: > >> Thanks for the clarification. It all SGTM. > > > > I've updated the PEP and the reference implementation. > > While I was saying loader when I should have been saying finder, Eric > correctly divined my intent :) > > > If I've missed > > anything please let me know. There is only one thing I thought of > > that I'd like to get an opinion on: > > > > In the Finders section, the PEP specifies returning None (or using a > > different loader) when the found loader does not support loading into > > an existing module (e.g during reload). An alternative to returning > > None would be for the finder to raise ImportError with a message like > > "the loader does not support reloading the module". This may actually > > be a better approach since "could not find a loader" and "the found > > loader won't work" are different situations that a single return value > > (None) may not sufficiently represent. > > Throwing ImportError for "can load, but cannot load into that target > module" sounds good to me. SGTM as well. > We should also be explicit that throwing an > exception from find_spec *stops* the search (unlike returning None). > I thought that was obvious but more docs doesn't hurt. =) > > > Other than that, I'm not aware of any blockers for the PEP. > > The one slight quibble I have with the PEP update is the wording > regarding the "existing" parameter. I think runpy should pass the new > parameter as well when calling find_spec, but in that case it *won't* > be an existing copy of the named module, it will be > sys.modules["__main__"]. So we shouldn't set an expectation that the > existing module passed in will necessarily be a previous copy of the > module being loaded, it's just an indication to the finder that the > target namespace for execution will be a pre-existing module rather > than a new one. > > For the same reason, I also have a mild preference for "target" (or > the more explicit "load_target") as the name, although I won't object > if you and Brett prefer "existing". I would go with "module" or "target" and that is where I shall end the bikeshedding. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 update
On 3 November 2013 01:21, Brett Cannon wrote: > On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan wrote: >> For the same reason, I also have a mild preference for "target" (or >> the more explicit "load_target") as the name, although I won't object >> if you and Brett prefer "existing". > > I would go with "module" or "target" and that is where I shall end the > bikeshedding. I had a quick reread of the runpy docs: http://docs.python.org/dev/library/runpy#runpy.run_module I can definitely make "target" work (that's why I suggested it originally, re-reading the docs just confirmed that), but I don't see any non-confusing way to use "module". Eric: since "target" was on both Brett's list and mine, it looks like s/existing/target/ and clarifying that "incompatible target module" should be reported by throwing ImportError from find_spec() will get you the pronouncement you're looking for :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Update NEWS for 265d369ad3b9.
In article <3dbmq94f4bz7...@mail.python.org>, jason.coombs wrote: > http://hg.python.org/cpython/rev/7d399099334d > changeset: 86861:7d399099334d > branch: 3.2 > user:Jason R. Coombs > date:Sat Nov 02 13:00:01 2013 -0400 > summary: > Update NEWS for 265d369ad3b9. > > files: > Misc/NEWS | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -10,6 +10,9 @@ > Library > --- > > +- Issue #19286: Directories in ``package_data`` are no longer added to > + the filelist, preventing failure outlined in the ticket. > + > - Issue #19435: Fix directory traversal attack on CGIHttpRequestHandler. > > - Issue #14984: On POSIX systems, when netrc is called without a filename The 3.2 branch is closed to all but security fixes with release manager approval. You shouldn't be checking bug fixes in there. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 451 update
On Sat, Nov 2, 2013 at 9:38 AM, Nick Coghlan wrote: > Eric: since "target" was on both Brett's list and mine, it looks like > s/existing/target/ and clarifying that "incompatible target module" > should be reported by throwing ImportError from find_spec() will get > you the pronouncement you're looking for :) Done and done! :) -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
