[Python-Dev] PEP 451 update

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 find_spec).
>> Yeah, I thought of that.  I just prefer the more explicit
>> supports_reload().  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

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,

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