On 2 November 2013 08:44, Eric Snow ericsnowcurren...@gmail.com wrote:
On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon br...@python.org 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
On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 2 November 2013 08:44, Eric Snow ericsnowcurren...@gmail.com wrote:
On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon br...@python.org wrote:
Thanks for the clarification. It all SGTM.
I've updated the PEP and the
On 3 November 2013 01:21, Brett Cannon br...@python.org wrote:
On Sat, Nov 2, 2013 at 5:46 AM, Nick Coghlan ncogh...@gmail.com 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
On Sat, Nov 2, 2013 at 9:38 AM, Nick Coghlan ncogh...@gmail.com 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
On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 1 Nov 2013 01:37, PJ Eby p...@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
On Thu, Oct 31, 2013 at 4:10 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Nov 1, 2013 at 7:35 AM, Brett Cannon br...@python.org wrote:
On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Nov 1, 2013 at 1:52 PM, Eric Snow ericsnowcurren...@gmail.comwrote:
On Fri, Nov 1, 2013 at 7:35 AM, Brett Cannon br...@python.org wrote:
On Thu, Oct 31, 2013 at 6:10 PM, Nick Coghlan ncogh...@gmail.com
wrote:
At the time when find_spec runs, sys.modules hasn't been touched yet, so
On Fri, Nov 1, 2013 at 11:59 AM, Brett Cannon br...@python.org 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
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan ncogh...@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
On 31 Oct 2013 18:52, Eric Snow ericsnowcurren...@gmail.com wrote:
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan ncogh...@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
On Thu, Oct 31, 2013 at 5:52 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 31 Oct 2013 18:52, Eric Snow ericsnowcurren...@gmail.com wrote:
On Wed, Oct 30, 2013 at 10:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
There's also the option of implementing the constraint directly in the
finder,
On 1 Nov 2013 01:37, PJ Eby p...@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
On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan ncogh...@gmail.com 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
On 31 Oct 2013 03:41, Eric Snow ericsnowcurren...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 31 Oct 2013 03:41, Eric Snow ericsnowcurren...@gmail.com wrote:
Our recent discovery about reloading should probably be reflected in
the signature of finder.find_spec():
MetaPathFinder.find_spec(name, path=None,
On 31 Oct 2013 08:54, Eric Snow ericsnowcurren...@gmail.com wrote:
On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 31 Oct 2013 03:41, Eric Snow ericsnowcurren...@gmail.com wrote:
Our recent discovery about reloading should probably be reflected in
the signature
On 29 Oct 2013 14:45, Eric Snow ericsnowcurren...@gmail.com wrote:
On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan ncogh...@gmail.com 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
On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 Oct 2013 14:45, Eric Snow ericsnowcurren...@gmail.com wrote:
I'd rather give loaders another optional method:
supports_reload(name). Complicating the spec methods signatures (to
support passing the old spec through)
On 30 October 2013 09:02, Eric Snow ericsnowcurren...@gmail.com wrote:
On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 29 Oct 2013 14:45, Eric Snow ericsnowcurren...@gmail.com wrote:
I'd rather give loaders another optional method:
supports_reload(name).
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
On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Oct 27, 2013 at 4:41 PM, PJ Eby p...@telecommunity.com 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
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com 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
On 28 Oct 2013 02:37, PJ Eby p...@telecommunity.com wrote:
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 Oct 2013 02:37, PJ Eby p...@telecommunity.com wrote:
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com wrote:
Now, regarding the signature of exec_module(): I'm back to believing
that loaders
On 28 Oct 2013 08:41, PJ Eby p...@telecommunity.com wrote:
On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 Oct 2013 02:37, PJ Eby p...@telecommunity.com wrote:
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan ncogh...@gmail.com
wrote:
Now, regarding the
On 26 October 2013 08:51, PJ Eby p...@telecommunity.com 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
On Fri, Oct 25, 2013 at 9:44 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon br...@python.org 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
On Sat, Oct 26, 2013 at 11:27 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 26 October 2013 08:51, PJ Eby p...@telecommunity.com 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
On 27 October 2013 03:27, Nick Coghlan ncogh...@gmail.com wrote:
On 26 October 2013 08:51, PJ Eby p...@telecommunity.com 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
On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan ncogh...@gmail.com 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
On 27 October 2013 14:29, Eric Snow ericsnowcurren...@gmail.com wrote:
On Sat, Oct 26, 2013 at 9:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
Accordingly, I think we should add a How Reloading Will Work
section, akin to the existing How Loading Will Work
On Thu, Oct 24, 2013 at 12:05 AM, Eric Snow ericsnowcurren...@gmail.com 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
On Thu, Oct 24, 2013 at 6:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 October 2013 16:05, Eric Snow ericsnowcurren...@gmail.com wrote:
* I've asserted that there shouldn't be much difficulty in adjusting
pkgutil and other modules to work with ModuleSpec.
More specifically: importlib
On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow ericsnowcurren...@gmail.comwrote:
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,
On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon br...@python.org 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
On Fri, Oct 25, 2013 at 11:44 AM, Eric Snow ericsnowcurren...@gmail.comwrote:
On Fri, Oct 25, 2013 at 9:40 AM, Brett Cannon br...@python.org 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__
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*
On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com 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
On Fri, Oct 25, 2013 at 10:24 AM, PJ Eby p...@telecommunity.com 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
On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon br...@python.org wrote:
On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com 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
On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby p...@telecommunity.com wrote:
On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon br...@python.org wrote:
On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com wrote:
At least through all 2.x, reload() just uses module.__name__ to
restart the
On Fri, Oct 25, 2013 at 3:15 PM, Brett Cannon br...@python.org wrote:
On Fri, Oct 25, 2013 at 2:10 PM, PJ Eby p...@telecommunity.com wrote:
On Fri, Oct 25, 2013 at 1:15 PM, Brett Cannon br...@python.org wrote:
On Fri, Oct 25, 2013 at 12:24 PM, PJ Eby p...@telecommunity.com wrote:
At least
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
On 24 October 2013 16:05, Eric Snow ericsnowcurren...@gmail.com 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
46 matches
Mail list logo
