Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Thu, May 24, 2012 at 12:33 PM, Guido van Rossum wrote: > I've reviewed the updates to the PEP and have accepted it. Congrats all! Congrats! -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Un

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/24/2012 2:33 PM, Guido van Rossum wrote: > I've reviewed the updates to the PEP and have accepted it. Congrats all! Thanks to the many people who helped: Martin, Barry, Guido, Jason, Nick, PJE, and others. I'm sure I've offended someone by leaving them out, and I apologize in advance. But sp

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

I've reviewed the updates to the PEP and have accepted it. Congrats all! I know the implementation is lagging behind a bit, that's not a problem. Just get it into the next 3.3 alpha release! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mail

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Thu, May 24, 2012 at 11:02 AM, Eric V. Smith wrote: > On 5/23/2012 8:58 PM, PJ Eby wrote: >> OTOH, that's finders, and I think we're dealing with loaders here. >> Splitting hairs, perhaps, but at least it's in a good cause.  ;-) > > I guess I could store the passed-in parent path, and use that

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 9:02 PM, Eric V. Smith wrote: > On 5/23/2012 8:58 PM, PJ Eby wrote: > > On Wed, May 23, 2012 at 8:24 PM, Eric V. Smith > > wrote: > > > > I tried this approach and it works fine. The only caveat is that it > > assumes that the parent pat

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/23/2012 8:58 PM, PJ Eby wrote: > On Wed, May 23, 2012 at 8:24 PM, Eric V. Smith > wrote: > > I tried this approach and it works fine. The only caveat is that it > assumes that the parent path can always be computed as described above, > independent of w

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 8:24 PM, Eric V. Smith wrote: > I tried this approach and it works fine. The only caveat is that it > assumes that the parent path can always be computed as described above, > independent of what's passed in to PathFinder.load_module(). I think > that's reasonable, since l

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

> Here's another suggestion: instead of modifying the finder/loader code > to pass these names through, assume that we can always find > (module_name, attribute_name) with this code: > > def find_parent_path_names(module): > parent, dot, me = module.__name__.rpartition('.') > if dot == '':

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/23/2012 03:56 PM, Brett Cannon wrote: > > > On Wed, May 23, 2012 at 3:35 PM, PJ Eby > wrote: > > On Wed, May 23, 2012 at 3:02 PM, Brett Cannon > wrote: > > If I understand the proposal correctly, this would be a cha

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 3:35 PM, PJ Eby wrote: > On Wed, May 23, 2012 at 3:02 PM, Brett Cannon wrote: > >> If I understand the proposal correctly, this would be a change in >> NamespaceLoader in how it sets __path__ and in no way affect any other code >> since __import__() just grabs the object

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 3:02 PM, Brett Cannon wrote: > If I understand the proposal correctly, this would be a change in > NamespaceLoader in how it sets __path__ and in no way affect any other code > since __import__() just grabs the object on __path__ and passes as an > argument to the meta pat

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 9:10 AM, Eric V. Smith wrote: > On 05/23/2012 09:02 AM, Nick Coghlan wrote: > > On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith > wrote: > >> On 05/22/2012 09:49 PM, PJ Eby wrote: > >>> It shouldn't - all you should need is to use > >>> getattr(sys.modules[self.modname],

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On May 23, 2012 9:02 AM, "Nick Coghlan" wrote: > > On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith wrote: > > On 05/22/2012 09:49 PM, PJ Eby wrote: > >> It shouldn't - all you should need is to use > >> getattr(sys.modules[self.modname], self.attr) instead of referencing a > >> parent path object

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/23/2012 09:02 AM, Nick Coghlan wrote: > On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith wrote: >> On 05/22/2012 09:49 PM, PJ Eby wrote: >>> It shouldn't - all you should need is to use >>> getattr(sys.modules[self.modname], self.attr) instead of referencing a >>> parent path object directly.

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith wrote: > On 05/22/2012 09:49 PM, PJ Eby wrote: >> It shouldn't - all you should need is to use >> getattr(sys.modules[self.modname], self.attr) instead of referencing a >> parent path object directly. > > The problem isn't the lookup, it's coming up

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/22/2012 09:49 PM, PJ Eby wrote: > On Tue, May 22, 2012 at 8:40 PM, Eric V. Smith > wrote: > > On 5/22/2012 2:37 PM, Guido van Rossum wrote: > > Okay, I've been convinced that keeping the dynamic path feature is a > > good idea. I am really looking forw

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 1:58 PM, PJ Eby wrote: > While I see no problem with cleaning up the interface, I'm kind of lost as > to the point of making a get_path callable, vs. just using the iterable > interface you sketched.  Python has iterables, so why add a call to get the > iterable, when iter(

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 9:58 PM, Nick Coghlan wrote: > If you wanted to do this without changing the sys.meta_path hook API, > you'd have to pass an object to find_module() that did the dynamic > lookup of the value in obj.__iter__. Something like: > >class _LazyPath: >def __init__(se

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 10:40 AM, Eric V. Smith wrote: > On 5/22/2012 2:37 PM, Guido van Rossum wrote: >> Okay, I've been convinced that keeping the dynamic path feature is a >> good idea. I am really looking forward to seeing the rationale added >> to the PEP -- that's pretty much the last thing

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 8:40 PM, Eric V. Smith wrote: > On 5/22/2012 2:37 PM, Guido van Rossum wrote: > > Okay, I've been convinced that keeping the dynamic path feature is a > > good idea. I am really looking forward to seeing the rationale added > > to the PEP -- that's pretty much the last thi

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/22/2012 2:37 PM, Guido van Rossum wrote: > Okay, I've been convinced that keeping the dynamic path feature is a > good idea. I am really looking forward to seeing the rationale added > to the PEP -- that's pretty much the last thing on my list that made > me hesitate. I'll leave the details of

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

Minor nit. On May 22, 2012, at 04:43 PM, PJ Eby wrote: >def declare_namespace(package_name): > parent, dot, tail = package_name.rpartition('.') > attr = '__path__' > if dot: >declare_namespace(parent) > else: >parent, attr = 'sys', 'path' > with importlockconte

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Tue, May 22, 2012 at 12:31 PM, Eric V. Smith wrote: > On 05/22/2012 11:39 AM, Nick Coghlan wrote: > > Oops, I also meant to say that it's probably worth at least issuing > > ImportWarning if a new portion with an __init__.py gets added - it's > > going to block all future dynamic updates of th

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

Okay, I've been convinced that keeping the dynamic path feature is a good idea. I am really looking forward to seeing the rationale added to the PEP -- that's pretty much the last thing on my list that made me hesitate. I'll leave the details of exactly how the parent path is referenced up to the i

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Mon, May 21, 2012 at 8:32 PM, Eric V. Smith wrote: > Any reason to make this the string "sys" or "foo", and not the module > itself? Can the module be replaced in sys.modules? Mostly I'm just curious. > Probably not, but it occurred to me that storing references to modules introduces a refere

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/22/2012 11:39 AM, Nick Coghlan wrote: > On Wed, May 23, 2012 at 12:51 AM, Eric V. Smith wrote: >> That seems like a pretty convincing example to me. >> >> Personally I'm +1 on putting dynamic computation into the PEP, at least >> for top-level namespace packages, and probably for all namespa

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 1:39 AM, Nick Coghlan wrote: >     def _recalculate(self): >         # If _parent_path has changed, recalculate _path >         parent_path = tuple(self._parent_path())     # Retrieve and make a > copy >         if parent_path != self._last_parent_path: >             loade

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Wed, May 23, 2012 at 12:51 AM, Eric V. Smith wrote: > That seems like a pretty convincing example to me. > > Personally I'm +1 on putting dynamic computation into the PEP, at least > for top-level namespace packages, and probably for all namespace packages. Same here, but Guido's right that th

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 05/21/2012 07:25 PM, Nick Coghlan wrote: > As a simple example to back up PJE's explanation, consider: > 1. encodings becomes a namespace package > 2. It sometimes gets imported during interpreter startup to initialise > the standard io streams > 3. An application modifies sys.path after startu

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/21/2012 2:08 PM, PJ Eby wrote: > On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum > wrote: > > Ah, I see. But I disagree that this is a reasonable constraint on > sys.path. The magic __path__ object of a toplevel namespace module > should know it is a to

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

I agree the parent path should be retrieved by name rather than a direct reference when checking the cache validity, though. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mail

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

As a simple example to back up PJE's explanation, consider: 1. encodings becomes a namespace package 2. It sometimes gets imported during interpreter startup to initialise the standard io streams 3. An application modifies sys.path after startup and wants to contribute additional encodings Search

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum wrote: > Ah, I see. But I disagree that this is a reasonable constraint on > sys.path. The magic __path__ object of a toplevel namespace module > should know it is a toplevel module, and explicitly refetch sys.path > rather than just keeping aroun

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On Mon, May 21, 2012 at 1:00 AM, Eric V. Smith wrote: > On 5/20/2012 9:33 PM, Guido van Rossum wrote: >> Generally speaking the PEP is a beacon if clarity. But I stumbled >> about one feature that bothers me in its specification and through its >> lack of rationale. This is the section on Dynamic

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

On 5/20/2012 9:33 PM, Guido van Rossum wrote: > Generally speaking the PEP is a beacon if clarity. But I stumbled > about one feature that bothers me in its specification and through its > lack of rationale. This is the section on Dynamic Path Computation: > (http://www.python.org/dev/peps/pep-0420