On Sat, Nov 2, 2013 at 9:38 AM, Nick Coghlan wrote:
> Eric: since "target" was on both Brett's list and mine, it looks like
> s/existing/target/ and clarifying that "incompatible target module"
> should be reported by throwing ImportError from find_spec() will get
> you the pronouncement you're lo
On 3 November 2013 01:21, Brett Cannon wrote:
> On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan wrote:
>> For the same reason, I also have a mild preference for "target" (or
>> the more explicit "load_target") as the name, although I won't object
>> if you and Brett prefer "existing".
>
> I would go
On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan wrote:
> On 2 November 2013 08:44, Eric Snow wrote:
> > On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote:
> >> Thanks for the clarification. It all SGTM.
> >
> > I've updated the PEP and the reference implementation.
>
> While I was saying loader
On 2 November 2013 08:44, Eric Snow wrote:
> On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote:
>> Thanks for the clarification. It all SGTM.
>
> I've updated the PEP and the reference implementation.
While I was saying loader when I should have been saying finder, Eric
correctly divined my in
On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon wrote:
> Thanks for the clarification. It all SGTM.
I've updated the PEP and the reference implementation. If I've missed
anything please let me know. There is only one thing I thought of
that I'd like to get an opinion on:
In the Finders section,
On Fri, Nov 1, 2013 at 1:52 PM, Eric Snow wrote:
> On Fri, Nov 1, 2013 at 7:35 AM, Brett Cannon wrote:
> > On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan
> wrote:
> >> At the time when find_spec runs, sys.modules hasn't been touched yet, so
> >> the old module state is still available when reload
On Fri, Nov 1, 2013 at 7:35 AM, Brett Cannon wrote:
> On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan wrote:
>> At the time when find_spec 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 o
On Thu, Oct 31, 2013 at 4:10 PM, Nick Coghlan wrote:
> However, perhaps it makes more sense to pass the entire existing module,
> rather than just the spec?
Sounds good to me. :)
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan wrote:
>
> On 1 Nov 2013 01:37, "PJ Eby" 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, an
On 1 Nov 2013 01:37, "PJ Eby" 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
On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan wrote:
>
> On 31 Oct 2013 18:52, "Eric Snow" wrote:
>>
>> On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan wrote:
>> > There's also the option of implementing the constraint directly in the
>> > finder, which *does* have the necessary info (with the ch
On 31 Oct 2013 18:52, "Eric Snow" wrote:
>
> On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan 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
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan 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
suppo
On 31 Oct 2013 08:54, "Eric Snow" wrote:
>
> On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> > On 31 Oct 2013 03:41, "Eric Snow" wrote:
> >> Our recent discovery about reloading should probably be reflected in
> >> the signature of finder.find_spec():
> >>
> >> MetaPathFinder.find_spec(
On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> On 31 Oct 2013 03:41, "Eric Snow" wrote:
>> Our recent discovery about reloading should probably be reflected in
>> the signature of finder.find_spec():
>>
>> MetaPathFinder.find_spec(name, path=None, existing=None)
>> PathEntryFinder.fin
On 31 Oct 2013 03:41, "Eric Snow" wrote:
>
> On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> > OK, time for me to stop trying to remember the details of the problem
> > I'm trying to solve and go look them up in the source code :)
> >
> > One of my goals here is to be able to migrate exten
On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> OK, time for me to stop trying to remember the details of the problem
> I'm trying to solve and go look them up in the source code :)
>
> One of my goals here is to be able to migrate extension loading from
> the old API to the new plugin API.
Nick Coghlan writes:
> OK, time for me to stop trying to remember the details of the problem
> I'm trying to solve and go look them up in the source code :)
OMG! Even Nick does that. I feel better now! ;)
___
Python-Dev mailing list
Python-Dev@pytho
On 30 October 2013 09:02, Eric Snow wrote:
> On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
>> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>>> I'd rather give loaders another optional method:
>>> supports_reload(name). Complicating the spec methods signatures (to
>>> support passing the old
On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>> I'd rather give loaders another optional method:
>> supports_reload(name). Complicating the spec methods signatures (to
>> support passing the old spec through) just for the sake of reload
>> seems
On 29 Oct 2013 14:45, "Eric Snow" wrote:
>
> On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan wrote:
> > I don't think we can postpone it to later, as we need to be clear on:
> >
> > 1. Does reload use __name__ or __spec__.name when both are available?
> > 2. Does __name__ get restored to its origi
On Sun, Oct 27, 2013 at 4:41 PM, PJ Eby wrote:
> I'm talking about userspace code that implements lazy importing
> features, like the lazyModule() function in this module:
>
>http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup
>
> Specifically, I'm trying to get an idea of how
On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan wrote:
> I don't think we can postpone it to later, as we need to be clear on:
>
> 1. Does reload use __name__ or __spec__.name when both are available?
> 2. Does __name__ get restored to its original value if reloading via
> __spec__.name?
> 3. Do ot
On 28 Oct 2013 08:41, "PJ Eby" wrote:
>
> On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
> >
> > On 28 Oct 2013 02:37, "PJ Eby" wrote:
> >>
> >> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan
wrote:
> >> > Now, regarding the signature of exec_module(): I'm back to believing
> >> > that loa
On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
>
> On 28 Oct 2013 02:37, "PJ Eby" wrote:
>>
>> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
>> > Now, regarding the signature of exec_module(): I'm back to believing
>> > that loaders should receive a clear indication that a reload is
On 28 Oct 2013 02:37, "PJ Eby" wrote:
>
> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
> > Now, regarding the signature of exec_module(): I'm back to believing
> > that loaders should receive a clear indication that a reload is taking
> > place. Legacy loaders have to figure that out for
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
> Now, regarding the signature of exec_module(): I'm back to believing
> that loaders should receive a clear indication that a reload is taking
> place. Legacy loaders have to figure that out for themselves (by
> seeing that the module already e
On 27 October 2013 14:29, Eric Snow wrote:
> On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan wrote:
>> 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
>> m
On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan 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
On 27 October 2013 03:27, Nick Coghlan wrote:
> On 26 October 2013 08:51, PJ Eby wrote:
>> Mostly, this just seems like an ugly wart -- Python should be dynamic
>> by default, and that includes reloading. While the import machinery
>> has lots of ugly caching under the hood, a user-level functio
On Sat, Oct 26, 2013 at 11:27 AM, Nick Coghlan wrote:
> On 26 October 2013 08:51, PJ Eby wrote:
>> Yeah, it actually was to ensure that you could reload a module using a
>> different loader than the one that originally loaded it, e.g. due to a
>> change in path hooks, etc.
>
> Yeah, the rationale
On Fri, Oct 25, 2013 at 9:44 AM, Eric Snow wrote:
> On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon wrote:
>> After reading Eric's doc patch, I realized there is one change I want to
>> make to the current semantics and that's not to backfill __package__ when
>> set to None. Since import is now goi
On 26 October 2013 08:51, PJ Eby wrote:
> Mostly, this just seems like an ugly wart -- Python should be dynamic
> by default, and that includes reloading. While the import machinery
> has lots of ugly caching under the hood, a user-level function like
> reload() should not require you to do the e
On Fri, Oct 25, 2013 at 3:15 PM, Brett Cannon wrote:
> On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby wrote:
>> On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon wrote:
>> > On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
>> >> At least through all 2.x, reload() just uses module.__name__ to
>> >> restart
On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby wrote:
> On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon wrote:
> >
> > On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
> >> At least through all 2.x, reload() just uses module.__name__ to
> >> restart the module find-and-load process, and does not assume t
On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon wrote:
>
> On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
>> At least through all 2.x, reload() just uses module.__name__ to
>> restart the module find-and-load process, and does not assume that
>> __loader__ is valid in advance.
>
>
> That doesn't m
On Fri, Oct 25, 2013 at 10:24 AM, PJ Eby wrote:
> I've not really had time to review this PEP yet, but from skimming
> discussion to date, the only thing I'm still worried about is whether
> this will break lazy import schemes that use a module subclass that
> hooks __getattribute__ and calls relo
On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby wrote:
> I've not really had time to review this PEP yet, but from skimming
> discussion to date, the only thing I'm still worried about is whether
> this will break lazy import schemes that use a module subclass that
> hooks __getattribute__ and calls rel
I've not really had time to review this PEP yet, but from skimming
discussion to date, the only thing I'm still worried about is whether
this will break lazy import schemes that use a module subclass that
hooks __getattribute__ and calls reload() in order to perform what's
actually an *initial* loa
On Fri, Oct 25, 2013 at 11:44 AM, Eric Snow wrote:
> On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon wrote:
> > After reading Eric's doc patch, I realized there is one change I want to
> > make to the current semantics and that's not to backfill __package__ when
> > set to None. Since import is now
On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon wrote:
> After reading Eric's doc patch, I realized there is one change I want to
> make to the current semantics and that's not to backfill __package__ when
> set to None. Since import is now going to take over the job of setting
> __package__ (along
On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow wrote:
> I've had some offline discussion with Brett and Nick about PEP 451
> which has led to some meaningful clarifications in the PEP. In the
> interest of pulling further discussions back onto this
> (archived/public) list, here's an update of what w
On Thu, Oct 24, 2013 at 6:01 AM, Nick Coghlan wrote:
> On 24 October 2013 16:05, Eric Snow wrote:
>> * I've asserted that there shouldn't be much difficulty in adjusting
>> pkgutil and other modules to work with ModuleSpec.
>
> More specifically: importlib finders will still expose the previous
>
On Thu, Oct 24, 2013 at 12:05 AM, Eric Snow wrote:
> * Nick suggested writing a draft patch for the language reference
> changes (the import page). Such a patch will be a pretty good
> indicator of the impact of PEP 451 on the import system and should
> highlight any design flaws in the API. Thi
On 24 October 2013 16:05, Eric Snow wrote:
> I've had some offline discussion with Brett and Nick about PEP 451
> which has led to some meaningful clarifications in the PEP. In the
> interest of pulling further discussions back onto this
> (archived/public) list, here's an update of what we'd dis
I've had some offline discussion with Brett and Nick about PEP 451
which has led to some meaningful clarifications in the PEP. In the
interest of pulling further discussions back onto this
(archived/public) list, here's an update of what we'd discussed and
where things are at. :)
* path entry fin
46 matches
Mail list logo
