Nick Coghlan [EMAIL PROTECTED] added the comment:
I should be able to review/commit this for the next alpha (looking into
it right now).
--
assignee: - ncoghlan
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
Paul Moore [EMAIL PROTECTED] added the comment:
Thanks,
Paul.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan [EMAIL PROTECTED] added the comment:
Commited as rev 62350
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
Paul Moore [EMAIL PROTECTED] added the comment:
Nick, thanks I now see the issue. I'll work up a test to check for this
(and then correct it :-)).
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
Phillip J. Eby [EMAIL PROTECTED] added the comment:
An easy way to test it: just change your load_module() to raise an
AssertionError if the module is already in sys.modules, and the main
body of the test to make two get_data() calls for the same module.
__
Paul Moore [EMAIL PROTECTED] added the comment:
But that's not a valid loader.
I'm still struggling here. I see what you're trying to get at, but I
can't see how I can write a valid loader that does this.
To test the problem you're suggesting (that the code calls load_module
when the module is
Phillip J. Eby [EMAIL PROTECTED] added the comment:
Why does it need to be a valid loader? It's a mock, not a real
loader. But if it really bothers you, have it increment a global in
the module or something, and put the assertion in the test
proper. Heck, have it update a counter in the
Paul Moore [EMAIL PROTECTED] added the comment:
It has to be a valid loader, as I see no reason to support loaders that
aren't valid. In any case, I did try incrementing a counter and it
doesn't demonstrate the problem. If you try the currently attached
patch, you should see that. (I assume
Phillip J. Eby [EMAIL PROTECTED] added the comment:
But I'm getting a failure on that test, and the other one, too:
$ ./python Lib/test/test_pkgutil.py
test_alreadyloaded (__main__.PkgutilTests) ... FAIL
test_getdata_filesys (__main__.PkgutilTests) ... FAIL
test_getdata_pep302
Paul Moore [EMAIL PROTECTED] added the comment:
Thanks for the update. Something's seriously screwy here. I am getting
no failures, so you can probably see why I was confused. Can you tell me
what platform, etc (anything that might be relevant) and I'll try to see
what's going on.
Paul Moore [EMAIL PROTECTED] added the comment:
By the way, for comparison, I'm running the test (under Windows) using
rt -q -v test_pkgutil from the PCBuild directory. I can't see how
test_getdata_filesys can fail, as long as you're running it from the
correct place - it reads the
Paul Moore [EMAIL PROTECTED] added the comment:
Ah, no. I see your command line. I get the same failure as you in that
case. I can see why test_getdata_filesys fails in that case, I'll fix
that. I'm confused as to why test_alreadyloaded fails there but not via
rt.bat, but nevertheless I can fix
Paul Moore [EMAIL PROTECTED] added the comment:
OK, I found it. There were 2 problems, the double-loading one, and a
problem with adding my importer to sys.meta_path - if the test failed, I
wasn't removing it (so it was there for the next test, and interfering
with it).
Here's a fixed patch.
Changes by Paul Moore [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9799/pkgutil.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list
New submission from Paul Moore [EMAIL PROTECTED]:
This patch adds a new get_data function to the pkgutil module, allowing
access to data stored in the package directory. It wraps the PEP 302
loader get_data function, so that it works with such loaders (for
example, zipimport).
The patch
Phillip J. Eby [EMAIL PROTECTED] added the comment:
Hi Paul. AFAICT, this doesn't look like it will actually work for
filesystem data. get_loader() will return None for regular,
filesystem-installed modules, at least in Python 2.5. Perhaps you
should add a test case for that?
--
Paul Moore [EMAIL PROTECTED] added the comment:
I'm not sure I understand. It uses pkgutil.get_loader, which returns a
wrapper for filesystem modules. You pointed me to it. It seems to work,
that's what test_getdata_filesys is testing in test_pkgutil.py.
Can you supply a testcase that fails?
Phillip J. Eby [EMAIL PROTECTED] added the comment:
Oops, my bad. I'm thinking of an entirely unrelated get_loader()
function. Meanwhile, I misread your patch entirely, and thought you had
some dead code for os.path processing that is in fact live. So there is
another problem (really the only
Paul Moore [EMAIL PROTECTED] added the comment:
Is that true? loader.load_module(pkg) should return sys.modules[pkg]
without reloading if it already exists. See PEP 302 Specification part
1: The Importer Protocol:
The load_module() method has a few responsibilities that it must
fulfil *before*
Changes by Paul Moore [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9792/pkgutil.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list
Phillip J. Eby [EMAIL PROTECTED] added the comment:
reload() is implemented by calling the PEP 302 load_module() method
on the existing module object.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
Nick Coghlan [EMAIL PROTECTED] added the comment:
To clarify the intent of the section of PEP 302 Paul quoted: the
*module* object gets reused, but the contents of mod.__dict__ are
clobbered and the module code re-executed.
So it's the same module object, but with brand new contents (this is
22 matches
Mail list logo
