At 01:19 PM 5/31/2010 -0700, Brett Cannon wrote:
But as long as whatever mechanism gets exposed allows people to work
from a module name that will be enough. The path connection is not
required as load_module is the end-all-be-all method. If we have a
similar API added for .pth files that works o
On Sun, May 30, 2010 at 22:03, P.J. Eby wrote:
> At 06:18 PM 5/30/2010 -0700, Brett Cannon wrote:
>>
>> On Sun, May 30, 2010 at 00:40, P.J. Eby wrote:
>> >
>> > Which would completely break one of the major use cases of the PEP,
>> > which is
>> > precisely to ensure that you can install two piec
On Mon, May 31, 2010 at 00:53, "Martin v. Löwis" wrote:
>> For finders, their search algorithm is changed in a couple of ways.
>> One is that modules are given priority over packages (is that
>> intentional, Martin, or just an oversight?).
>
> That's an oversight. Notice, however, that it's really
At 09:24 AM 5/31/2010 +0200, Martin v. Löwis wrote:
Is this really how it works today? Shouldn't it abort here
if there is an ImportError?
Oops. You're right - I was confusing find_module with the path_hooks
protoocol.
>else:
># errors here should propagate
>
The PEP says the goal is to span packages across directories. If you
split something like zope into multiple directories, does having a
separate zope.pth file in each of those directories really cause a
problem here?
I think pje already answered this: yes, you do split zope into multiple
packag
For finders, their search algorithm is changed in a couple of ways.
One is that modules are given priority over packages (is that
intentional, Martin, or just an oversight?).
That's an oversight. Notice, however, that it's really not the case that
currently directories have precedence over modul
Looking at that proposal, I don't follow how changing *loaders* (vs.
importers) would help. If an importer's find_module doesn't natively
support PEP 382, then there's no way to get a loader for the package in
the first place.
True. However, this requires no changes to the API, AFAICT. The *find
At 06:18 PM 5/30/2010 -0700, Brett Cannon wrote:
On Sun, May 30, 2010 at 00:40, P.J. Eby wrote:
>
> Which would completely break one of the major use cases of the
PEP, which is
> precisely to ensure that you can install two pieces of code to the same
> namespace without either one overwriting
At 05:59 PM 5/30/2010 -0700, Brett Cannon wrote:
Is it wise to modify __path__ post-import? Today people can make sure
that __path__ is set to what they want before potentially reading it
in their __init__ module by making the pkgutil.extend_path() call
first. This would actually defer to after t
On Sun, May 30, 2010 at 00:40, P.J. Eby wrote:
> At 03:44 PM 5/29/2010 -0700, Brett Cannon wrote:
>>
>> On Sat, May 29, 2010 at 12:29, "Martin v. Löwis"
>> wrote:
>> > Am 29.05.2010 21:06, schrieb P.J. Eby:
>> >>
>> >> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
>>
>> In it he s
On Sat, May 29, 2010 at 15:56, P.J. Eby wrote:
> At 09:29 PM 5/29/2010 +0200, Martin v. Löwis wrote:
>>
>> Am 29.05.2010 21:06, schrieb P.J. Eby:
>>>
>>> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
>
> In it he says that PEP 382 is being deferred until it can address PEP
> 302
At 03:44 PM 5/29/2010 -0700, Brett Cannon wrote:
On Sat, May 29, 2010 at 12:29, "Martin v. Löwis" wrote:
> Am 29.05.2010 21:06, schrieb P.J. Eby:
>>
>> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 l
At 09:29 PM 5/29/2010 +0200, Martin v. Löwis wrote:
Am 29.05.2010 21:06, schrieb P.J. Eby:
At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP
On Sat, May 29, 2010 at 12:29, "Martin v. Löwis" wrote:
> Am 29.05.2010 21:06, schrieb P.J. Eby:
>>
>> At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't s
Am 29.05.2010 21:06, schrieb P.J. Eby:
At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote:
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP 382 about PEP 302 loaders, so I assume this issue wa
In it he says that PEP 382 is being deferred until it can address PEP
302 loaders. I can't find any follow-up to this. I don't see any
discussion in PEP 382 about PEP 302 loaders, so I assume this issue was
never resolved. Does it need to be before PEP 382 is implemented? Are we
wasting our time b
16 matches
Mail list logo
