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
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
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
Is it possible with svn or hg to get a list of the commits that changed
version x to version y?
A regular "svn log" on the maintenance branch will give you all the
changes. You'll recognize from the checkin messages when the previous
release was.
Would is not be possible to get a diff betwe
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
>
Hi,
when embedding python 3.1, I have my own free-method in tp_dealloc.
The allocated memory is in host-memory, not in python (dll). Now, the problem
is, Python appears to read-access the deallocated memory still after
tp_dealloc. After tp_dealloc, I get an access violation if the pyobject-header
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
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
In issue 1759169 people have been demanding for quite some time that the
definition of _XOPEN_SOURCE on Solaris should be dropped, as it was
unneeded and caused problems for other software.
Now, issue 8864 reports that the multiprocessing module fails to
compile, and indeed, if _XOPEN_SOURCE i
sm...@gmx.net wrote:
Now, the problem is, Python appears to read-access the deallocated memory
still after tp_dealloc.
It's not clear exactly what you mean by "after tp_dealloc".
The usual pattern is for a type's tp_dealloc method to call
the base type's tp_dealloc, which can make further refer
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
11 matches
Mail list logo
