[issue23731] Implement PEP 488

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue23731> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: I've opened a feature clone to better track the work (features/cordereddict). Here's the updated patch against default from that clone. I haven't added any argument client stuff. I also haven't addressed any of the feedback from Antoin

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: s/argument client/Argument Clinic/ -- ___ Python tracker <http://bugs.python.org/issue16991> ___ ___ Python-bugs-list mailin

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: I expect Antoine is trying to limit the scope of the change, which makes sense. In this case, though, once (if?) the patch lands I plan on using it in the interpreter, so the C-API bits will be necessary. -- ___ Python

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Thanks for speaking up, Antoine. Keep in mind that a C implementation of OrderedDict has a strict compatibility requirement with the existing pure Python one. The Python implementation subclasses dict so the C implementation must as well. I agree that it would

[issue23731] Implement PEP 488

Eric Snow added the comment: Thanks for doing this, Brett. It's so simple a change yet such a great one. :) -- ___ Python tracker <http://bugs.python.org/is

[issue21319] WindowsRegistryFinder never added to sys.meta_path

Eric Snow added the comment: Awesome. Thanks Tim. -- ___ Python tracker <http://bugs.python.org/issue21319> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23882] unittest discovery and namespaced packages

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue23882> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23882] unittest discovery and namespaced packages

Eric Snow added the comment: Is there any reason for unittest to not use pkgutil.iter_modules or pkgutil.walk_packages? Either should work. -- ___ Python tracker <http://bugs.python.org/issue23

[issue23910] C implementation of namedtuple (WIP)

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue23910> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23911] Move path-based bootstrap code to a separate frozen file.

New submission from Eric Snow: The bootstrap code has a clear division between the core import functionality and the path-based import machinery. The attached patch makes that division explicit by moving the latter into its own module. The module is also frozen, necessarily. In addition to

[issue23731] Implement PEP 488

Eric Snow added the comment: LGTM -- ___ Python tracker <http://bugs.python.org/issue23731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: Note that (in my mind, unfortunately) the pickle module looks up several dunder methods on instances. That isn't quite the same thing since the issue is about callable not triggering the descriptor protocol. However it is closely related. I point this out be

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: > What would be the "right thing"? My suggestion of using a metaclass is actually not effective here because __call__ has meaning for metaclasses. Otherwise you could have made __call__ more dynamic via a metaclass. Except that is another

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: Just to be clear, I'm still -1 on any of this. On the one hand, there's a risk of backward-compatibility breakage (just as much a corner-case as the need expressed in this issue). On the other hand, I'd actually push for _PyObject_LookupSpecial

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: s/TypeError/RuntimeError/ -- ___ Python tracker <http://bugs.python.org/issue23990> ___ ___ Python-bugs-list mailing list Unsub

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: > Ionel Cristian Mărieș added the comment: > #1. "It's specified/documented, therefore it's intended" > > The first thing a maintainer does is check the docs. This is a sensible thing > to do - as you cannot have all the details

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: > Ionel Cristian Mărieș added the comment: > It's not. Did you see the example with iter()/__iter__? It does convert > the AttributeError into a TypeError. callable and iter are not the same thing though. callable checks for a capability. iter invoke

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: > Ionel Cristian Mărieș added the comment: > What exactly are you proposing? Getting rid of AttributeError masking? That isn't really a practical thing to consider, so no. :) Instead I'm suggesting there isn't a lot of justification to c

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Here's an updated patch, with the PEP 489 changes merged in. Only one test isn't passing and it is due to something in the pip that is bundled into ensurepip. I'll work on fixing that when I have some time. I'm sure there's documenta

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: s/PEP 489/PEP 488/ -- ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24014] Second pass of PyCode_Optimize

Eric Snow added the comment: > Also, Python/importlib.h blew up in the diff; should this be included in the patch? Yes. It is the frozen bytecode for bootstrapping importlib as the import system. So changes to bytecode generation like this will propagate there. -- nosy: +eric.s

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: > Ionel Cristian Mărieș added the comment: > Also, descriptors are a core mechanism in new-style classes - you can't > have methods without descriptors. Why would you even consider removing > descriptors from the special method lookup if that

[issue23990] Callable builtin doesn't respect descriptors

Eric Snow added the comment: FYI, I'll re-iterate something I said before, there is a different approach you can take here if this is just an issue of proxying. Use two different proxy types depending on if the proxied object is callable or not: class Proxy: # all the proxy

[issue24020] threading.local() must be run at module level (doc improvement)

Eric Snow added the comment: FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope. I don't think anything needs to be fixed here. The SO answer is misleading and perhaps even w

[issue24020] threading.local() must be run at module level (doc improvement)

Changes by Eric Snow : -- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <http://bugs.python

[issue24020] threading.local() must be run at module level (doc improvement)

Eric Snow added the comment: @Ethan, it may help you to read through the module docstring in Lib/_threading_local.py. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24020] threading.local() must be run at module level (doc improvement)

Eric Snow added the comment: Think of threading.local this way: instances of threading.local are shared between all the threads, but the effective "__dict__" of each instance is per-thread. Basically, the object stores a dict for each thread. In __getattribute__, __seta

[issue24029] Surprising name binding behavior of submodule imports needs documenting

Eric Snow added the comment: Guido describes the global invariant for *all* the forms of importing a submodule, including explicit relative imports: > I just mean that for relative import > there is no need to bind the submodule to the parent, is there? But there *is* a reason. The sub

[issue24029] Surprising name binding behavior of submodule imports needs documenting

Eric Snow added the comment: LGTM. You've covered all the key points and the example is good. -- ___ Python tracker <http://bugs.python.org/issue24029> ___ ___

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Glad to hear the patch is conceptually consistent with other components. :) And the "internal"/"external" suggestion is a good one. I'll update the patch when I have a minute. --

[issue11205] Evaluation order of dictionary display is different from reference manual.

Eric Snow added the comment: Changes to importlib.h should always be committed. It is the frozen importlib._bootstrap module, which is the implementation of the import system used by the interpreter. So failure to commit changes to importlib.h means your changes to importlib._bootstrap will

[issue24081] Obsolete caveat in reload() docs

Eric Snow added the comment: Either the docs are out-of-date or they are really poorly worded. Most likely it's the former, but I'm taking a look. -- ___ Python tracker <http://bugs.python.o

[issue24081] Obsolete caveat in reload() docs

Eric Snow added the comment: I've verified that the documentation is correct under Python 2.3. The behavior changed under Python 2.4 (and the docs were not updated). I expect that the change in behavior is an unintended consequence of a change in the import system for 2.4. There were

[issue24081] Obsolete caveat in reload() docs

Eric Snow added the comment: I'm pretty sure this is the culprit: changeset: 32882:331e60d8ce6da19b168849418776fea0940787ec branch: legacy-trunk user:Tim Peters date:Mon Aug 02 03:52:12 2004 + summary: PyImport_ExecCodeModuleEx(): remove module from sys.mo

[issue24081] Obsolete caveat in reload() docs

Eric Snow added the comment: patch LGTM for the 3 branches. -- ___ Python tracker <http://bugs.python.org/issue24081> ___ ___ Python-bugs-list mailing list Unsub

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Here's an updated patch with "_pathy.py" changed to "_bootstrap_external.py" (and similar changes with freezing). The patch does not include fixing the venv test (i.e. the bundled pip). Also, I'll be adding a note to NEWS

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: As I mentioned, I'm pretty sure that the failing venv test is due to the bundled pip. Here's the test output: test test_venv failed -- Traceback (most recent call last): File "/home/esnow/projects/cpython/Lib/test/test_venv.py", line 35

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Looks like setuptool's pkg_resources is directly importing importlib._bootstrap. I've filed a bug: https://bitbucket.org/pypa/setuptools/issue/378. In the meantime, what are our options for getting that te

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Here's the correct patch. -- Added file: http://bugs.python.org/file39272/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/is

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : Removed file: http://bugs.python.org/file39271/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bug

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Gah. I had tried exactly that but did it in the wrong spot. Here's an updated patch which fixes the test. -- Added file: http://bugs.python.org/file39273/path-based-importlib.diff ___ Python tracker

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : Removed file: http://bugs.python.org/file39273/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bug

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : Added file: http://bugs.python.org/file39274/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bug

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : Added file: http://bugs.python.org/file39275/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bug

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : Removed file: http://bugs.python.org/file39274/path-based-importlib.diff ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bug

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : -- resolution: -> fixed status: open -> pending ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bugs-list

[issue23911] Move path-based bootstrap code to a separate frozen file.

Changes by Eric Snow : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue23911> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: Thanks for pointing this out, Ned. Early on I ran into a problem when running _freeze_importlib without the flag set. However, I expect that it was not necessary after a certain point (e.g. once I had a valid _importlib_external.h). I'll remove the fl

[issue23911] Move path-based bootstrap code to a separate frozen file.

Eric Snow added the comment: changeset: 95887:3bea670c9830 user:Eric Snow date:Tue May 05 21:29:31 2015 -0600 summary: Remove an unnecessary flag. -- resolution: -> fixed stage: needs patch -> resolved status: open -&g

[issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name

Eric Snow added the comment: Just in case, please take a look at issues #17457 and #23882 to see if they already cover the bug. -- nosy: +eric.snow, rbcollins ___ Python tracker <http://bugs.python.org/issue24

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: @Yury, I'm mostly just waiting for Raymond to give it at least a quick sanity-check. I know there is at least 1 ref leak, but that can be sorted out. -- ___ Python tracker <http://bugs.python.org/is

[issue16991] Add OrderedDict written in C

Changes by Eric Snow : -- priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/issue16991> ___ ___ Python-bugs-list mailing list Un

[issue24192] unexpected system error with pep420 style namespace packages

Eric Snow added the comment: The problem is right where the traceback says. Apparently there is a gap in the namespace package tests that I slipped through with my recent work to split out path-based import. I'll work up a patch. -- ___ P

[issue24192] unexpected system error with pep420 style namespace packages

Eric Snow added the comment: Hmm, look like the test suite masks the issue due to the fact that importlib gets imported before running the applicable tests in test_namespace_pkgs.py. This causes _frozen_importlib.__package__ to get set properly, thus masking the problem. The problem is the

[issue24192] unexpected system error with pep420 style namespace packages

Eric Snow added the comment: Here's a fix. If I don't hear from anyone right away I'll push it in a few hours (or tomorrow morning). -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39386/issue24192.diff

[issue24192] unexpected system error with pep420 style namespace packages

Changes by Eric Snow : -- assignee: -> eric.snow ___ Python tracker <http://bugs.python.org/issue24192> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue24192] unexpected system error with pep420 style namespace packages

Changes by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> pending type: -> behavior ___ Python tracker <http://bugs.python

[issue24192] unexpected system error with pep420 style namespace packages

Eric Snow added the comment: Great! The buildbots are happy too. :) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue24192> ___ ___ Py

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Thanks for taking a look, Yury. I'll follow up on the ref leak soon. -- ___ Python tracker <http://bugs.python.org/is

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: I've updated the cordereddict branch on the feature repo to fix the ref leak on None. I'm still seeing other leaks (regrtest -R 3:3), but I don't think that should block landing before the feature freeze. However, I'm concerned about a segfaul

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Agreed. I wanted to be clear about what is blocking landing the patch. -- ___ Python tracker <http://bugs.python.org/issue16

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: These are the leaks I'm seeing in test_collections (14/24 tests): test_copying : 178 test_iterators : 40 test_update : 29 test_init: 22 test_move_to_end : 21 test_sorted_iterators: 20 test_setdefault

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: I've fixed most of the leaks now. The only remaining ones are: test_clear : 5 test_repr_recursive : 3 -- ___ Python tracker <http://bugs.python.org/is

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Regarding the segfault, the following does not fail: ./python -m test.regrtest --forever -m test_basic test_configparser but this does: for i in `seq 1 20`; do ./python -m test.regrtest -m test_basic test_configparser ; done

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Here's a diff from the current cordereddict branch of the feature repo. -- Added file: http://bugs.python.org/file39445/cOrderedDict-4.diff ___ Python tracker <http://bugs.python.org/is

[issue24254] Make class definition namespace ordered by default

New submission from Eric Snow: Here's a work-in-progress patch that uses OrderedDict as the default class definition namespace (instead of dict). While the actual class namespace is a dict, the definition order is preserved on a new attribute on class objects: __definition_order__. Th

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Thanks for looking into this, Ned. I've changed that size_t to ssize_t which I expect will quiet that clang warning you saw. I'm glad you pointed it out because it means that that branch was never executing! Unfortunately fixing that does not so

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Cool. The following gives consistent failures at certain seed values: for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m test.regrtest -m test_basic test_configparser ; done Through 100 I get segfaults with 7, 15, 35, 37, 39, 40, 42, 47, 50, 66, 67

[issue24254] Make class definition namespace ordered by default

Eric Snow added the comment: Here's a patch that drops adding __definition_order__. You can get the same effect by adding `__definition_order__ = list(locals())` at the bottom of your class definition. The benefit of having `__definition_order__` is that the information is automati

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: I've spent a bit of time exploring the segfault. Here's some data that might help relative to the configparser test. I put the following at the beginning of _odict_resize: Py_ssize_t len = PyObject_Size((PyObject *)od); if

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: As far as I can tell there aren't any patterns that repeat across multiple seeds (which makes sense). -- ___ Python tracker <http://bugs.python.org/is

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Here are the last 10 frames from the backtrace (gdb): #0 0x005b15d0 in odictiter_iternext (di=) at Objects/odictobject.c:1888 #1 0x00453179 in PyIter_Next (iter=) at Objects/abstract.c:2760 #2 0x005881e7 in chain_next (lz=0x72b8d878

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: The segfault happens at line 1888 of odictobject.c when it tries to Py_INCREF a NULL value. The problem is that the value that gets looked up for a presumably valid key is returned as NULL. So either the value is messed up, lookup is broken, or the wrong key is

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Yeah, Ned pointed that one out. I fixed it but haven't pushed the change. -- ___ Python tracker <http://bugs.python.org/is

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Include/opcode.h shouldn't be in the change (and won't be when committed). I'm guessing it being there is related to one of the recent merges I did from default into the feature branch. -- ___ Python

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Just to narrow things down a bit further, the failure happens specifically under ConfigParserTestCaseNoValue: PYTHONHASHSEED=7 ./python -m unittest test.test_configparser.ConfigParserTestCaseNoValue.test_basic -v

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: If I still the following at Lib/test/test_configparser.py:328: print(len(cf._proxies), len(list(cf._proxies)), list(cf._proxies)) print(len(cf._sections), len(list(cf._sections)), list(cf._sections)) I get unexpected results that are a clear indication of a

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Good point, Nick. I'd checked that earlier but did not see any relationship. At this point it's worth checking again. :) -- ___ Python tracker <http://bugs.python.o

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: Good catch. I've fixed odictiter_new in the feature branch. However, I'm not sure there's anything to be fixed in odict_new. It follows the same pattern as dict_new (over in Objects/dictobject.c). -- ___

[issue16991] Add OrderedDict written in C

Changes by Eric Snow : -- hgrepos: +309 ___ Python tracker <http://bugs.python.org/issue16991> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24254] Make class definition namespace ordered by default

Changes by Eric Snow : -- hgrepos: +310 ___ Python tracker <http://bugs.python.org/issue24254> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: @mrab gah! I could swear I originally had the _odict_clear_node first and had switched them due to a segfault. It even crossed my mind on Friday but I didn't pursue it. I'm guessing I did put the _odict_clear_node call first at some point but los

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: @Jim, You've got some good questions. I'll look into them today. -- ___ Python tracker <http://bugs.python.org/issue16991> ___ __

[issue24254] Make class definition namespace ordered by default

Changes by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*

Eric Snow added the comment: I have verified that this is still a problem (basically 3.6b1). Fatal Python error: Py_Initialize: Unable to get the locale encoding Traceback (most recent call last): File "/opt/python3.6/lib/python3.6/encodings/__init__.py", line 99, in search_funct

[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*

Eric Snow added the comment: After looking more closely, it looks like we should be ignoring such bogus modules. Here's a patch to do so. -- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file44424/issue16

[issue27997] ImportError should be raised consistently from import machinery.

New submission from Eric Snow: As indicated by issue #16384, the import machinery is not consistent in raising ImportError. Some places in _bootstrap.py (and _bootstrap_external.py) raise ImportError and others make no effort to wrap errors that get encountered. I would expect the import

[issue28005] Broken encoding modules are silently skipped.

New submission from Eric Snow: In Lib/encodings/__init__.py, search_function() looks up an encoding by name. It loads the encoding by importing the corresponding module in the encodings package. If there's an ImportError while importing that module then the encoding gets silently ig

[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*

Eric Snow added the comment: Here's an updated patch. Per a suggestion from Brett, I've chained the original EOFError with an ImportError. The consequence is that the problematic encoding is skipped (silently) rather than causing the interpreter to abort. FYI, I've opened

[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*

Changes by Eric Snow : Removed file: http://bugs.python.org/file44424/issue16384.diff ___ Python tracker <http://bugs.python.org/issue16384> ___ ___ Python-bugs-list m

[issue15767] add ModuleNotFoundError

Changes by Eric Snow : -- assignee: brett.cannon -> eric.snow resolution: rejected -> stage: -> needs patch status: closed -> open versions: +Python 3.6 -Python 3.4 ___ Python tracker <http://bugs.python

[issue28007] Bad .pyc files prevent import of otherwise valid .py files.

New submission from Eric Snow: As pointed out in #16384, a bad .pyc file will cause a module to fail importing. Sometimes the .py file is okay, however. The question posed in the other issue is if it would be desirable to fall back to the .py file. FWIW, I don't think it'

[issue16384] import.c doesn't handle EOFError from PyMarshal_Read*

Eric Snow added the comment: I've opened #28007 to cover the concerns about bad a .pyc file blocking import from a valid .py file. -- ___ Python tracker <http://bugs.python.org/is

[issue15767] add ModuleNotFoundError

Changes by Eric Snow : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue17211] pkgutil.iter_modules and walk_packages should return a namedtuple

Eric Snow added the comment: I've applied the patch with a couple small changes. Thanks for the help! -- nosy: +eric.snow resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 -Python 3.4 ___ Python

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow added the comment: Thanks for the patch Meador. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 -Python 3.3 ___ Python tracker <http://bugs.python.or

[issue15578] Crash when modifying sys.modules during import

Changes by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue15272] pkgutil.find_loader accepts invalid module names

Eric Snow added the comment: pkgutil has since been updated to use importlib, meaning it relies on importlib to sort this out. -- components: +Library (Lib) resolution: -> out of date stage: needs patch -> resolved status: open -> closed versions: +Python 3.6 -P

<    21   22   23   24   25   26   27   >