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

PJ Eby pje at telecommunity.com
Thu Oct 31 16:36:53 CET 2013

On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 31 Oct 2013 18:52, "Eric Snow" <ericsnowcurrently at gmail.com> wrote:

On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > There's also the option of implementing the constraint directly in the > finder, which does have the necessary info (with the change to pass > the > previous spec to findspec). Yeah, I thought of that. I just prefer the more explicit supportsreload(). That said... > > I still think it makes more sense to leave this out for the moment - > it's > not at all clear we need the extra method, and adding it later would be > a > straightforward protocol update. ...I agree that makes the most sense for now. :) BTW, thanks for pushing these issues. I think the API has gotten pretty solid. I just need to make sure the PEP covers the cases and conclusions we're discussing. Thanks are also due to PJE for making me realise we were handwaving too much when it came to the expected reload semantics :)

You're welcome. ;-) But speaking of handwaving, I also want to be sure that loader developers know that "reloading" is only really "reloading" if there's a previous existing spec, or the module type is...

Hm. Actually, I think I now know how to state what's bugging me every time I see this "supports_reload()" or "reload=True" or other reloading flags in this process.

I think that references to reloading should be replaced with references to what's actually at issue, because "reloading" itself is vague and carries too many assumptions for a loader author to understand or get right. (Look how hard it is for us!)

That is, I think we should clarify what use cases there are for knowing whether a "reload" is happening, and address those use cases explicitly rather than lumping them under a general heading.

For example, if the reason a loader cares about reloading is because it's a C extension using a custom module type, and the existing module isn't of the right type, then we should just spell out how to handle it. (e.g. raise an exception)

If the reason a loader cares about reloading is because of some sort of caching or reuse, then we should just spell out how to handle that, too.

Lumping these cases together under a "reloading" flag or a check for "reloading" support is a nasty code smell, because it requires a loader developer to have the same vaguely-defined idea of "reloading" as the PEP authors. ;-)

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". ;-)

More information about the Python-Dev mailing list