[Python-Dev] PEP 451 update (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Sun Oct 27 05:29:29 CET 2013
- Previous message: [Python-Dev] PEP 451 update
- Next message: [Python-Dev] PEP 451 update
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
I've been thinking about this, and I've come to the conclusion that:
1. The old name based behaviour was broken (since name may not be the actual module name, as in "main" or when a pseudo-module is lying about its identity) 2. The 3.3 behaviour is still broken for similar reasons and added the dependency on loader 3. Even PEP 451 still underspecifies the semantics of reloading (e.g. it's implied createmodule isn't called for reload(), but not stated explicitly) Accordingly, I think we should add a "How Reloading Will Work" section, akin to the existing "How Loading Will Work" (http://www.python.org/dev/peps/pep-0451/#how-loading-will-work). We may also want to spit out some import warnings for edge cases that are likely to do the wrong thing.
I'm tempted to just say reload should not be a blocker for PEP 451. The premise is that the PEP mostly maintains the status quo, just shifting reload-based-on-loader to reload-based-on-spec (it's still "load the same way you did the first time").
I agree that it would be worth getting reload working right, but I'm not convinced it's worth it to delay PEP 451 more for the sake of reload.
Side note: in "How Loading Will Work", initmoduleattrs needs to be passed both the module and the spec (current text only passes it the module).
Good catch. Fixed!
It also needs to be updated to handle the namespace package case (as shown below)
I knew I missed something. I'll fix this, but it may be a couple days before I get a minute. :(
-eric
- Previous message: [Python-Dev] PEP 451 update
- Next message: [Python-Dev] PEP 451 update
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]