Eric Snow added the comment:
Given that issue14657 wrapped up, I'm closing this issue too.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
Antoine Pitrou pit...@free.fr added the comment:
Happened again on one of the Windows buildbots:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6436/steps/test/logs/stdio
==
FAIL:
Antoine Pitrou pit...@free.fr added the comment:
Some entries in sys.path_importer_cache are named _frozen_importlib.FileFinder,
and others are named importlib._bootstrap.FileFinder. Isn't that a bit
worrying? Two copies of importlib are loaded in memory? (and functioning
independently?)
Brett Cannon br...@python.org added the comment:
Issue #14657 is tracking the discussion of
_frozen_importlib/importlib._bootstrap.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
Brett Cannon br...@python.org added the comment:
Then how do you explain the failure being nothing more than prepending .
compared to an absolute file path?
Anyway, the test passes under importlib with ``./python.exe -m
importlib.test.regrtest test_imp``, so it requires some special setup to
Stefan Krah stefan-use...@bytereef.org added the comment:
I think there's another problem on Windows even after the fix:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4463
==
FAIL:
Brett Cannon br...@python.org added the comment:
This is issue #14052 all over again, just with a different test.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
___
Antoine Pitrou pit...@free.fr added the comment:
This is issue #14052 all over again, just with a different test.
I don't think so, because I've whacked the part of importlib that transformed
'' into os.getcwd().
--
___
Python tracker
Stefan Krah stefan-use...@bytereef.org added the comment:
So the test needs to be fixed to call importlib.invalidate_caches()
after creating the module.
That works. With issue14080.diff I can run the failing combination
without problems:
$ ./python -m test test_sqlite test_imp
[1/2]
Brett Cannon br...@python.org added the comment:
importlib.invalidate_caches() would become a permanent thing if the directory
listdir cache approach stays and importlib gets bootstrapped. But it would be
made more general to work for any and all loaders and not be specific to
importlib (e.g.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 1d7472b015f0 by Antoine Pitrou in branch 'default':
Issue #14080: fix sporadic test_imp failure. Patch by Stefan Krah.
http://hg.python.org/cpython/rev/1d7472b015f0
--
nosy: +python-dev
Antoine Pitrou pit...@free.fr added the comment:
Thanks for diagnosing this :)
--
assignee: brett.cannon -
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
I've trouble debugging this: Is the new version of importlib already
being used? I'm stepping through the offending pep3147 import, which
should correspond to this line in test_dot.py:
m = __import__('pep3147')
Until here
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
___
___
Antoine Pitrou pit...@free.fr added the comment:
Is this expected?
Looks rather strange to me, it means we have importlib importers on
sys.path_importer_cache. Still, the fact that path == '.' above (in
_FileFinder as well as find_module_path) makes it difficult to
understand the later
Stefan Krah stefan-use...@bytereef.org added the comment:
OK, I stepped in parallel through the non-failing and the failing
versions. The first divergence is when _path_mtime is compared.
The comparison in the good version returns 'False', the one in the
bad version returns 'True':
Good version
Stefan Krah stefan-use...@bytereef.org added the comment:
So I think the good version proceeds to refresh the _path_cache:
_FileFinder(_relaxed_path_cache={'pep3147'}, packages=[('.py', type at remote
0xaaff60), ('.pyc', type at remote 0xab02e0)], _path_mtime=float at remote
0xa66120,
Stefan Krah stefan-use...@bytereef.org added the comment:
And indeed, with this patch ...
diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -777,6 +777,8 @@
mtime =
Antoine Pitrou pit...@free.fr added the comment:
Le samedi 25 février 2012 à 16:59 +, Stefan Krah a écrit :
Bad version:
$ ./python -m test test_dot
[1/1] test_dot
1330188676.0 1330188676.0
This might be what triggers the issue, but it's not the cause. Even with
a bad mtime, the
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
This might be what triggers the issue, but it's not the cause. Even with
a bad mtime, the __file__ should still be the right one, so there must
be something else.
It definitely triggers the
Stefan Krah stefan-use...@bytereef.org added the comment:
What happens is that if self._fill_cache() is called, cache_module='pep3147'
and cache={'pep3147'}. Then 'cache_module in cache' is true and the function
returns:
loader('pep3147', './pep3147/__init__.py')
Otherwise, find_module()
Antoine Pitrou pit...@free.fr added the comment:
What happens is that if self._fill_cache() is called, cache_module='pep3147'
and cache={'pep3147'}. Then 'cache_module in cache' is true and the function
returns:
loader('pep3147', './pep3147/__init__.py')
Otherwise, find_module()
Brett Cannon br...@python.org added the comment:
I think the test is bogus. It would do better to either use str.endswith() or
splitting off the various parts of __file__ to verify the filename is correct
as is the directory. Otherwise it shouldn't matter if the directory is relative
or
Antoine Pitrou pit...@free.fr added the comment:
Otherwise it shouldn't matter if the directory is relative or absolute.
That's not really the issue here, both are relative.
I am still baffled at that failure, I don't see why would be chosen over .
(which is inserted at the beginning of
Brett Cannon br...@python.org added the comment:
Well, if you execute test_imp w/ importlib (-m importlib.test.regrtest
test_imp) it still passes. So there is something very odd going on that
probably relies on some other test doing something weird. And this might be
hard to diagnose until
Stefan Krah stefan-use...@bytereef.org added the comment:
OK, on FreeBSD the failure occurs reliably when test_sqlite and
test_imp are chained, perhaps because of the import failure
of sqlite3:
[stefan@freebsd-amd64 ~/hg/cpython]$ ./python -m test -uall test_sqlite test_imp
[1/2] test_sqlite
Antoine Pitrou pit...@free.fr added the comment:
OK, on FreeBSD the failure occurs reliably when test_sqlite and
test_imp are chained, perhaps because of the import failure
of sqlite3:
Mmh, funny, I can't trigger it here. Is there anything special in your
sys.path?
--
Stefan Krah stefan-use...@bytereef.org added the comment:
No, this is sys.path after sys.path.insert(0, os.curdir):
['.', '', '/usr/local/lib/python33.zip', '/usr/home/stefan/hg/cpython/Lib',
'/usr/home/stefan/hg/cpython/Lib/plat-freebsd9',
Brett Cannon br...@python.org added the comment:
I can confirm the failure when an import fails prior to running test_imp (i.e.
trying importing some non-existent module like Stefan did at the top of
test_imp). Luckily importlib doesn't fail in this case. =)
--
Antoine Pitrou pit...@free.fr added the comment:
I can confirm the failure when an import fails prior to running
test_imp (i.e. trying importing some non-existent module like Stefan
did at the top of test_imp). Luckily importlib doesn't fail in this
case. =)
I can't reproduce :( Can either
Brett Cannon br...@python.org added the comment:
I'd rather get importlib working fast enough that you are okay with
bootstrapping it so we can delete the offending code. =)
--
___
Python tracker rep...@bugs.python.org
Stefan Krah stefan-use...@bytereef.org added the comment:
Here's a minimal test case for now. It only fails if called as -m test:
$ ./python Lib/test/test_dot.py # OK
$ ./python Lib/test/regrtest.py test_dot # OK
[1/1] test_dot
Warning -- sys.path was modified by test_dot
$
Stefan Krah stefan-use...@bytereef.org added the comment:
Antoine, what is your gcc version? The test case I posted fails
with Debian/gcc-4.3.2 and Ubuntu/gcc-4.4.3. The two affected
buildbots have gcc-4.2.x.
But the test case passes on Fedora/gcc-4.6.
--
Antoine Pitrou pit...@free.fr added the comment:
Antoine, what is your gcc version? The test case I posted fails
with Debian/gcc-4.3.2 and Ubuntu/gcc-4.4.3. The two affected
buildbots have gcc-4.2.x.
Mageia/gcc-4.5.2 here. It also passes with Debian/gcc-4.4.5.
--
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
___
___
Python-bugs-list
New submission from Antoine Pitrou pit...@free.fr:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1845/steps/test/logs/stdio
==
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
Antoine Pitrou pit...@free.fr added the comment:
Updated build URL (the buildbot changed name):
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/1845/steps/test/logs/stdio
--
___
Python tracker rep...@bugs.python.org
37 matches
Mail list logo
