[Python-Dev] PEP 451 update (original) (raw)

Brett Cannon brett at python.org
Fri Nov 1 14:35:38 CET 2013

On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 1 Nov 2013 01:37, "PJ Eby" <pje at telecommunity.com> wrote: . ;-) > > I also suspect, that if properly spelled out, those use cases are > going to boil down to: > > 1. Throwing errors if you have an existing module object you can't > load into, and > 2. Passing in a previous spec object, if available > > In other words, loaders should not really have any responsibility for > or concept of "reloading" -- they always load into a module object > (that they may or may not have created), and they may get given a spec > from a previous load. They should deal only in "module reuse" and > "spec reuse". While a typical reload() might involve both reuses, > there are cases where one sort of reuse could occur independently, and > not all loaders care about both (or even either) condition. > > At any rate, it means a loader author doesn't have to figure out how > to handle "reloading", all they have to figure out is whether they can > load into a particular module object, and whether they can do > something useful with a spec that was previously used to load a module > with the same name -- a spec that may or may not refer to a similar > previous loader. These are rather more well-defined endeavors than > trying to determine in the abstract whether one "supports reload". > ;-) It may not have been clear from the email exchange, but that's basically where we ended up :) The change Eric is currently going to make to the PEP is to add an optional "previous" parameter to the various findspec APIs. At the time when findspec runs, sys.modules hasn't been touched yet, so the old module state is still available when reloading. Passing the spec in lets the loader decide whether or not it can actually load that module given the information about the previous load operation. Do you mean loader or finder? You say "find_spec" which is for finders, but then you say "loader".

However, perhaps it makes more sense to pass the entire existing module, rather than just the spec? I'd like to minimise the need for new-style loader authors to retrieve things directly from the sys module, and you're right that "can I reload into this particular module?" is a slightly different question from "can I reload a module previously loaded using this particular spec?".

A spec-based API could still be used to answer the first question by looking up sys.modules, but so could the name based API. Passing in the module reference, on the other hand, should let loaders answer both questions without needing to touch the sys module. I also now think this pass-the-module approach when finding the spec approach could also clean up some of the messiness that is main initialisation, where we repeatedly load things into the same module object.

See you mention "finding" but before now everything has been "loader".

Let's say we be completely explicit and call the new parameter something like "loadtarget". If we do that then I would make the same change to runpy.runpath and runpy.runmodule: let you pass in an existing module object under that name to say "hey, run in this namespace, rather than a fresh one". (Those APIs currently only support pre-populating a fresh namespace, rather than allowing you to directly specify an existing one)

Most loaders won't care, but those that do will have all the info they need to throw an exception saying "I could provide a spec for this, but it's not compatible with that load target". Exactly what APIs -- new or changed -- are you proposing? Method signatures only please to avoid ambiguity. =) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131101/9f7d09bf/attachment.html>

More information about the Python-Dev mailing list