[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
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
[issue38109] Missing constants in Lib/stat.py
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
[issue38109] Missing constants in Lib/stat.py
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
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
[issue25130] Make tests more PyPy compatible
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
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
[issue38095] Multi-threaded circular import fails with _DeadlockError when using importlib
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
[issue38091] Import deadlock detection causes deadlock
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
[issue26917] unicodedata.normalize(): bug in Hangul Composition
Ronan Lamy <ronan.l...@gmail.com> 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 <rep...@bugs.python.org> <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 <ronan.l...@gmail.com> 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 <rep...@bugs.python.org> <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.l...@gmail.com> 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 <rep...@bugs.python.org> <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
New submission from Ronan Lamy <ronan.l...@gmail.com>: 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 <rep...@bugs.python.org> <https://bugs.python.org/issue31984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15482] __import__() change between 3.2 and 3.3
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 string, line 1, in module
File ./foo/__init__.py, line 1, in module
__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 rep...@bugs.python.org
http://bugs.python.org/issue15482
___
___
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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue15288 ___ ___ 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.l...@gmail.com 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 rep...@bugs.python.org 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
Changes by Ronan Lamy ronan.l...@gmail.com: -- nosy: +Ronan.Lamy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12982 ___ ___ 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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
New submission from Ronan Lamy ronan.l...@gmail.com: 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 rep...@bugs.python.org 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
New submission from Ronan Lamy ronan.l...@gmail.com: 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com added the comment: My preferred solution would be to use to use the functions I describe in issue 15031. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15030 ___ ___ 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.l...@gmail.com 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 rep...@bugs.python.org 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
Changes by Ronan Lamy ronan.l...@gmail.com: -- nosy: +Ronan.Lamy ___ Python tracker rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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.l...@gmail.com 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 rep...@bugs.python.org 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
New submission from Ronan Lamy ronan.l...@gmail.com:
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 rep...@bugs.python.org
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.l...@gmail.com 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 rep...@bugs.python.org
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.l...@gmail.com added the comment: Grmf. I didn't mean to change the status. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
