[issue38091] Import deadlock detection causes deadlock

[Ronan Lamy]

New submission from Ronan Lamy :

There seems to be a race condition in importlib._bootstrap._ModuleLock that can 
cause a deadlock. The sequence of operations is as follows:

* Thread 1 calls lock.acquire()
* Thread 1 sets itself as lock.owner and begins importing the module
* Thread 2 calls lock.acquire() and waits for lock.lock
* Thread 2 gets lock.lock
* Thread 1 calls lock.acquire() again, due to a nested import
* Thread 1 sets itself as blocking on lock: _blocking_on[tid1] = lock
* Thread 2 enters lock.has_deadlock()
* Thread 2 busy-waits forever in has_deadlock() because lock.owner == tid1 and 
_blocking_on[tid1] == lock
* Thread 1 waits forever for lock.lock since thread 2 owns it

The issue was found in pypy3 but it also affects all the recent CPython 
versions I tried.
I can reliably reproduce the issue by adding an artificial delay to 
_ModuleLock.has_deadlock(), e.g. with this patch:

diff --git a/Lib/test/test_import/__init__.py b/Lib/test/test_import/__init__.py
index f167c84..7f7188e 100644
--- a/Lib/test/test_import/__init__.py
+++ b/Lib/test/test_import/__init__.py
@@ -435,10 +435,15 @@ class ImportTests(unittest.TestCase):
 os.does_not_exist
 
 def test_concurrency(self):
+def delay_has_deadlock(frame, event, arg):
+if event == 'call' and frame.f_code.co_name == 'has_deadlock':
+time.sleep(0.2)
+
 sys.path.insert(0, os.path.join(os.path.dirname(__file__), 'data'))
 try:
 exc = None
 def run():
+sys.settrace(delay_has_deadlock)
 event.wait()
 try:
 import package

--
components: Library (Lib)
messages: 351647
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: Import deadlock detection causes deadlock
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38091>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38095] Multi-threaded circular import fails with _DeadlockError when using importlib

[Ronan Lamy]

New submission from Ronan Lamy :

The IMPORT_NAME bytecode has a fast path calling 
PyImport_ImportModuleLevelObject() that behaves differently from importlib. In 
particular, test_circular_imports() in test_threaded_import.py fails due to a 
_DeadlockError if you replace some import statements with 
importlib.import_module() as in

diff --git a/Lib/test/test_importlib/test_threaded_import.py 
b/Lib/test/test_importlib/test_threaded_import.py
index d1f64c7..243d2c1 100644
--- a/Lib/test/test_importlib/test_threaded_import.py
+++ b/Lib/test/test_importlib/test_threaded_import.py
@@ -60,8 +60,12 @@ circular_imports_modules = {
 x = 'b'
 import D
 """,
-'C': """import B""",
-'D': """import A""",
+'C': """if 1:
+import importlib
+B = importlib.import_module('B')""",
+'D': """if 1:
+import importlib
+A = importlib.import_module('A')""",
 }

--
components: Library (Lib)
messages: 351738
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: Multi-threaded circular import fails with _DeadlockError when using 
importlib
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38095>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38109] Missing constants in Lib/stat.py

[Ronan Lamy]

New submission from Ronan Lamy :

According to the docs, stat should include constants S_IFDOOR, S_IFPORT, 
S_IFWHT as well as the related S_IS... functions. However, these are only 
defined in _stat. I know that stat is a bit special (see bpo-11016), but that 
goes against PEP 399.

--
components: Library (Lib)
messages: 351870
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: Missing constants in Lib/stat.py
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25130] Make tests more PyPy compatible

[Ronan Lamy]

Change by Ronan Lamy :


--
nosy: +Ronan.Lamy

___
Python tracker 
<https://bugs.python.org/issue25130>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38109] Missing constants in Lib/stat.py

[Ronan Lamy]

Change by Ronan Lamy :


--
keywords: +patch
pull_requests: +16248
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16665

___
Python tracker 
<https://bugs.python.org/issue38109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38109] Missing constants in Lib/stat.py

[Ronan Lamy]

Ronan Lamy  added the comment:

Well, my interest in this is to reduce the divergence between PyPy and CPython, 
and, potentially, to help other implementations. So I actually care more about 
3.7 than about 3.9, which I probably won't look at before 2021.

That said, I don't *need* anything: the fix is already in PyPy and we'll carry 
it forward regardless of what CPython does.

--

___
Python tracker 
<https://bugs.python.org/issue38109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38109] Missing constants in Lib/stat.py

[Ronan Lamy]

Ronan Lamy  added the comment:

Thanks Victor!

--

___
Python tracker 
<https://bugs.python.org/issue38109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Ronan Lamy]

Change by Ronan Lamy :


--
nosy: +Ronan.Lamy

___
Python tracker 
<https://bugs.python.org/issue37645>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26917] unicodedata.normalize(): bug in Hangul Composition

[Ronan Lamy]

Ronan Lamy  added the comment:

Victor's patch is correct. I implemented the same fix in PyPy in 
https://bitbucket.org/pypy/pypy/commits/92b4fb5b9e58

--
nosy: +Ronan.Lamy

___
Python tracker 
<https://bugs.python.org/issue26917>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31984] startswith and endswith leak implementation details

[Ronan Lamy]

New submission from Ronan Lamy :

One would think that u.startswith(v, start, end) would be equivalent to 
u[start: end].startswith(v), but one would be wrong. And the same goes for 
endswith(). Here is the actual spec (for bytes, but str and bytearray are the 
same), in the form of passing pytest+hypothesis tests:


from hypothesis import strategies as st, given

def adjust_indices(u, start, end):
if end < 0:
end = max(end + len(u), 0)
else:
end = min(end, len(u))
if start < 0:
start = max(start + len(u), 0)
return start, end

@given(st.binary(), st.binary(), st.integers(), st.integers())
def test_startswith_3(u, v, start, end):
if v:
expected = u[start:end].startswith(v)
else:
start0, end0 = adjust_indices(u, start, end)
expected = start0 <= len(u) and start0 <= end0
assert u.startswith(v, start, end) is expected

@given(st.binary(), st.binary(), st.integers(), st.integers())
def test_endswith_3(u, v, start, end):
if v:
expected = u[start:end].endswith(v)
else:
start0, end0 = adjust_indices(u, start, end)
expected = start0 <= len(u) and start0 <= end0
assert u.endswith(v, start, end) is expected

Fixing this behaviour to work in the "obvious" way would be simple: just add a 
check for len(v) == 0 and always return True in that case.

--
messages: 305881
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: startswith and endswith leak implementation details
type: behavior
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue31984>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31984] startswith and endswith leak implementation details

[Ronan Lamy]

Ronan Lamy  added the comment:

The problem is the complexity of the actual behaviour of these methods. 

It is impossible to get it right without looking at the source (at least, it 
was for me), and I doubt any ordinary user can correctly make use of the v='' 
behaviour, or predict what the return value will be in all cases.

--

___
Python tracker 
<https://bugs.python.org/issue31984>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31984] startswith and endswith leak implementation details

[Ronan Lamy]

Ronan Lamy  added the comment:

Ah, thanks, I noticed the discrepancy between unicode and str in 2.7, but 
wondered when it was fixed. I guess I'm arguing that it was resolved in the 
wrong direction, then.

Now, your first expression is wrong, even after fixing the obvious typo. The 
correct version is:
start + len(s2) <= min(len(s1), end) and s1[start: start + len(s2)] == s2

If the person who implemented the behaviour can get it right, who will? ;-)

The second expression is correct, but I'll argue that it shows that find() also 
suffers from a discrepancy between its basic one-argument form and the extended 
ones.

--

___
Python tracker 
<https://bugs.python.org/issue31984>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

New submission from Ronan Lamy :

If an __init__.py file contains relative imports, doing 'import 
my_pkg.__init__' or calling __import__('my_pkg.__init__') creates duplicate 
versions of the relatively imported modules, which (I believe) causes cryptic 
errors in some cases (cf. the metaclass issue in 
http://code.google.com/p/sympy/issues/detail?id=3272 ).

More precisely, with my_pkg/__init__.py containing (see attachment for the full 
setup):

from .module1 import a
from my_pkg.module2 import b

I get:

Python 3.3.0a3+ (default:0685f51e9891, May 27 2012, 02:22:12) 
[GCC 4.6.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import my_pkg.__init__
>>> import sys
>>> sorted(name for name in sys.modules if name.startswith('my_'))
['my_pkg', 'my_pkg.__init__', 'my_pkg.__init__.module1', 'my_pkg.module1', 
'my_pkg.module2']
>>> 

Note the bogus 'my_pkg.__init__.module1' entry. For reference, in Python 3.2, 
the last line is:

['my_pkg', 'my_pkg.__init__', 'my_pkg.module1', 'my_pkg.module2']


NB: calling __import__('my_pkg.__init__') might seem odd (I didn't actually 
expect it to work on any Python version), but doctest apparently relies on it 
to test __init__.py files.

--
components: Interpreter Core
files: my_pkg.tar.bz2
messages: 161799
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: 'import my_pkg.__init__' creates duplicate modules
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25749/my_pkg.tar.bz2

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

my_pkg.__init__ isn't treated as just another module but as a package. That is 
the reason why the bogus my_pkg.__init__.module1 is created, I guess:

>>> import sys
>>> sorted(name for name in sys.modules if name.startswith('my_'))
[]
>>> import my_pkg.__init__
>>> sorted(name for name in sys.modules if name.startswith('my_'))
['my_pkg', 'my_pkg.__init__', 'my_pkg.__init__.module1', 'my_pkg.module1', 
'my_pkg.module2']
>>> sys.modules['my_pkg.module1'].__package__
'my_pkg'
>>> sys.modules['my_pkg.__init__'].__package__
'my_pkg.__init__'

I agree that importing __init__ is a hack, but the way 3.3 reacts to it is 
nasty, because it can cause a whole application to be executed multiple times.

--
resolution: wont fix -> 
status: closed -> open

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Grmf. I didn't mean to change the status.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Well, I can try. I have trouble wrapping my head around all the finders and 
loaders, but I'm slowly understanding what does what.

What I don't know is what the expected behaviour is. Should my_pkg.__init__ be 
allowed to exist as a separate module (that's backwards-compatible but seems 
wrong)? Can it exist as a synonym of my_pkg? Should the import attempt raise an 
ImportError?

--

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Reverting to the previous behaviour, then? OK.

As I understand it, the issue comes from a DRY violation: both 
FileFinder.find_loader() and _LoaderBasics.is_package() have their own notion 
of what is a package and they disagree. Since the finder needs to know what is 
a package, I think that the loader should be told whether it's a package or not 
instead of trying to guess.

--

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

That would force the Loaders to know how to convert a module name into a file 
path, which isn't the case now since FileLoader.get_filename() is just a shim 
that returns self.path. So I'd rather add an optional argument to FileLoader. 
Actually, I feel that the clean solution would be to have packages be a 
separate Loader class, but that would be a significant change...

--

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Here's a preliminary patch, without tests or documentation, implementing my 
approach (adding an optional is_package=False to FileLoader.__init__()).

Next question (quite independent of the chosen implementation): how should this 
be tested?

--
keywords: +patch
Added file: http://bugs.python.org/file25789/1.patch

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Your second solution is simple and solves the problem, so I guess that's it, 
then. 

Still, I don't really understand the purpose of SourceLoader, which makes me 
uneasy about the implementation of _LoaderBasics.is_package(). It seems to be 
meant to load an arbitrary resource yet it assumes that get_filename returns an 
actual file path, so I don't see how it could be used to import from a URL, for 
instance.

--

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

OK, that makes sense pragmatically.

Here's the patch then. I wasn't sure where to put the test, it doesn't actually 
have much in common with the rest of 
Lib/importlib/test/import_/test_packages.py but the name fits, so...

--
Added file: http://bugs.python.org/file25792/2.patch

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14982] pkgutil.walk_packages seems to not work properly on Python 3.3a

[Ronan Lamy]

Changes by Ronan Lamy :


--
nosy: +Ronan.Lamy

___
Python tracker 
<http://bugs.python.org/issue14982>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

I'm not sure that it's enough to test is_package() because that only involves 
the loader and not the interaction between it and FileFinder. That's the reason 
why my test works at a higher level.

BTW, I sent the contributor agreement.

--

___
Python tracker 
<http://bugs.python.org/issue14938>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15030] PyPycLoader can't read cached .pyc files

[Ronan Lamy]

New submission from Ronan Lamy :

PyPycLoader can't read or write .pyc files created by the core import 
machinery. I'm attaching a failing test case demonstrating the issue: if you 
import a .py file using standard mechanisms, thus creating a .pyc, and then (in 
a separate process, say) attempt to make use of that cached file with 
PyPycLoader, the import fails with 'ValueError: bad marshal data (unknown type 
code)'.

It looks like that there has been a change in the binary format of .pyc files 
but PyPycLoader wasn't updated.

--
components: Library (Lib)
files: test_PyPyc.diff
keywords: patch
messages: 162486
nosy: Ronan.Lamy, brett.cannon
priority: normal
severity: normal
status: open
title: PyPycLoader can't read cached .pyc files
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25859/test_PyPyc.diff

___
Python tracker 
<http://bugs.python.org/issue15030>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15031] Split .pyc parsing from module loading

[Ronan Lamy]

New submission from Ronan Lamy :

I think it would be beneficial to extract the handling of the binary format of 
bytecode files from the rest of the loader/finder code in importlib._bootstrap. 
That means exposing, internally at least, functions that do nothing more than 
convert the binary contents of a .pyc file to/from metadata + code object. They 
would help in testing and implementing alternate loaders and would prevent the 
kind of code duplication that led to issue 15030.

I'm adding a patch implementing extracting a _loads_pyc() function from 
_bytes_to_bytecode(). Note that:

* _loads_pyc() has only one parameter, instead of 5 for _bytes_from_bytecode.
* The raising of exceptions is more consistent: _loads_pyc being an IO helper, 
it never raises ImportError. Thanks to exception chaining, no information is 
lost, though.

Obviously, this should be complemented with a _dumps_pyc(). Then there's the 
question of whether these functions should be public and what the best 
interface is - I actually feel that the natural home of both functions is in a 
lower level module, either imp or marshal.

So, should I get on with it, or are there things I overlooked that make this a 
bad idea?

--
components: Interpreter Core
files: loads_pyc.diff
keywords: patch
messages: 162489
nosy: Ronan.Lamy, brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Split .pyc parsing from module loading
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25860/loads_pyc.diff

___
Python tracker 
<http://bugs.python.org/issue15031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15030] PyPycLoader can't read cached .pyc files

[Ronan Lamy]

Ronan Lamy  added the comment:

2.7 doesn't have PyPycLoader. For 3.2, it's such a pain to create a working 
concrete subclass of PyPycLoader that I gave up. But just by reading the code, 
it doesn't seem affected, as there's no discrepancy with importlib._bootstrap: 
they both consider that metadata are the first 8 bytes (in default, _bootstrap 
switched to using 12 bytes).

--

___
Python tracker 
<http://bugs.python.org/issue15030>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15030] PyPycLoader can't read cached .pyc files

[Ronan Lamy]

Ronan Lamy  added the comment:

My preferred solution would be to use to use the functions I describe in issue 
15031.

--

___
Python tracker 
<http://bugs.python.org/issue15030>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15031] Split .pyc parsing from module loading

[Ronan Lamy]

Ronan Lamy  added the comment:

I see. However, I think that breaking code noisily is better than breaking it 
silently, which is what happens when the same protocol is reimplemented many 
times. And _loads_pyc() could be made more forward-compatible by returning 
(path_stats, code) instead of (timestamp, size, code).

--

___
Python tracker 
<http://bugs.python.org/issue15031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15030] PyPycLoader can't read cached .pyc files

[Ronan Lamy]

Ronan Lamy  added the comment:

Well, working on a deprecated ABC is certainly low-priority, but it seems 
rather bad to have 2 incompatible implementations of the .pyc format in the 
stdlib. If this is to stay like this, it should at least come with a strong 
warning that users of PyPycLoader must invent their own PEP 3147 magic tag, 
which opens the can of worms of supporting multiple .pyc formats within the 
same interpreter in the stdlib. 

It seems easier to just fix it to be compatible with the one blessed .pyc 
format, as was the case in 3.2.

--

___
Python tracker 
<http://bugs.python.org/issue15030>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12982] Document that importing .pyo files needs python -O

[Ronan Lamy]

Changes by Ronan Lamy :


--
nosy: +Ronan.Lamy

___
Python tracker 
<http://bugs.python.org/issue12982>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12982] Document that importing .pyo files needs python -O

[Ronan Lamy]

Ronan Lamy  added the comment:

Doing it at the interpreter level is trivial (cf. patch), except for an 
annoying bug I noticed (see below). Doing it from user code might require some 
care to avoid disrupting existing import hooks, but AFAICT something like 
sys.path_hooks.append(FileFinder.path_hook(['.pyo', SourcelessFileLoader, 
True])) is supposed to work. 

The bug is that -O has currently no effect on sourceless imports: it seems that 
frozen_importlib actually uses freeze-time __debug__ instead of the current 
interpreter's.

--
keywords: +patch
Added file: http://bugs.python.org/file26008/issue12982.diff

___
Python tracker 
<http://bugs.python.org/issue12982>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15297] pkgutil.iter_importers() includes an ImpImporter

[Ronan Lamy]

Ronan Lamy  added the comment:

AFAICT, the intent of this function was to help provide a fully PEP-302 
compliant import process wrapping the builtin C-implemented import mechanism. 
Nowadays, I believe that iterating over sys.meta_path should probably be enough.

--
nosy: +Ronan.Lamy

___
Python tracker 
<http://bugs.python.org/issue15297>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15288] Clarify the pkgutil.walk_packages() note

[Ronan Lamy]

Ronan Lamy  added the comment:

It seems that most, if not all, uses of "importer" in pkgutil refer to finders, 
e.g. ImpImporter is a actually only a finder, not an importer. So 
s/importer/finder/ is needed, and perhaps also a note explaining that 
ImpImporter isn't in fact an importer, in addition to glossary links.

--
nosy: +Ronan.Lamy

___
Python tracker 
<http://bugs.python.org/issue15288>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15482] __import__() change between 3.2 and 3.3

[Ronan Lamy]

New submission from Ronan Lamy:

I noticed a change in the behaviour of __import__() between 3.2 and 3.3. It 
looks like in 3.2 __import__() does a Py2-style combo relative/absolute import. 
Here's a minimal test case:

$ ls foo
bar.py  __init__.py  __pycache__
$ cat foo/__init__.py
__import__('bar', globals(), locals())
$ python3.3 -c "import foo"
Traceback (most recent call last):
  File "", line 1, in 
  File "./foo/__init__.py", line 1, in 
__import__('bar', globals(), locals())
ImportError: No module named 'bar'
$ python3.2 -c "import foo"
$

I believe that 3.3 is correct and that 3.2 is wrong but can't be changed now, 
so I suppose that 3.2 should just document the actual behaviour of __import__() 
and 3.3 should document the change. 

(The context is that I encountered issue 15434. This looks related, but I'm not 
sure it is.)

--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 166706
nosy: Ronan.Lamy, brett.cannon, docs@python, ncoghlan
priority: normal
severity: normal
status: open
title: __import__() change between 3.2 and 3.3
versions: Python 3.2, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue15482>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com