Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 451 update
PJ Ebypje 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 besure that loader developers know that "reloading" is only really"reloading" if there's a previous existing spec, or the module typeis...Hm. Actually, I think I now know how to state what's bugging meevery time I see this "supports_reload()" or "reload=True" or otherreloading flags in this process.I think that references to reloading should be replaced withreferences to what's *actually* at issue, because "reloading" itselfis vague and carries too many assumptions for a loader author tounderstand or get right. (Look how hard it is for *us*!)That is, I think we should clarify what use cases there are forknowing whether a "reload" is happening, and address those use casesexplicitly rather than lumping them under a general heading.For example, if the reason a loader cares about reloading is becauseit's a C extension using a custom module type, and the existing moduleisn't of the right type, then we should just spell out how to handleit. (e.g. raise an exception)If the reason a loader cares about reloading is because of some sortof 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 aloader 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 aregoing to boil down to:1. Throwing errors if you have an existing module object you can'tload into, and2. Passing in a previous spec object, if availableIn other words, loaders should not really have any responsibility foror concept of "reloading" -- they always load into a module object(that they may or may not have created), and they may get given a specfrom 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, andnot all loaders care about both (or even either) condition.At any rate, it means a loader author doesn't have to figure out howto handle "reloading", all they have to figure out is whether they canload into a particular module object, and whether they can dosomething useful with a spec that was previously used to load a modulewith the same name -- a spec that may or may not refer to a similarprevious loader. These are rather more well-defined endeavors thantrying to determine in the abstract whether one "supports reload".;-)
More information about the Python-Devmailing list
[8]ページ先頭