[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader

Eric Snow added the comment: source_to_code() seems like a good fit on InspectLoader to me. Is there something in particular that motivated the idea of moving it up to Loader? -- nosy: +eric.snow ___ Python tracker <http://bugs.python.

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: Sounds good to me. -- ___ Python tracker <http://bugs.python.org/issue20383> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader

Eric Snow added the comment: Now that I've thought about it a little more, I'm more open to the idea. Source is definitely a universal concept in Python, as is code. So source_to_code() makes some sense on a most-base type like Loader. On the other hand, source isn't necessa

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: I made roughly the same point in the current import-sig thread that relates here: https://mail.python.org/pipermail/import-sig/2014-April/000805.html Basically, I agree we should be careful with both __name__ and __file__

[issue21181] Inconsistent Definition of collections.namedtuple.__dict__ in _source

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

[issue20434] Process crashes if not enough memory to import module

Eric Snow added the comment: I don't see a review link. Looks like your patch wasn't against tip (at attach-time) or you used the --git flag in diff. Having the patch in the review tool would be really would be really helpful. I'll take a look otherwise, but won't be

[issue21200] pkgutil.get_loader() fails on "__main__"

New submission from Eric Snow: Prior to 3.4, pkgutil.get_loader('__main__') would return None. Now it results in an ImportError. That's because it calls importlib.util.find_spec() which fails if an existing module does not have __spec__ or it is None. -- component

[issue16991] Add OrderedDict written in C

Eric Snow added the comment: After pulling up to tip and sticking in the basic **kwargs change, the results on the benchmark suite imply a refleak somewhere. As soon as I sort that out I'll push up the updated patch. -- ___ Python tracker

[issue21200] pkgutil.get_loader() fails on "__main__"

Eric Snow added the comment: Here's a patch that checks for modules that don't have __spec__ set. The patch will fix the problem. However note that the docs and docstring imply (to me) that we should turn any ImportError coming out of the find_loader() call into returning None. F

[issue21211] pkgutil.find_loader() raises ImportError instead of returning None

New submission from Eric Snow: In 3987667bf98f pkgutil.find_loader() switched from using pkgutil.iter_importers() to importlib.find_module(). importlib.find_module() checks the module's __loader__ (and raises ImportError when invalid) whereas iter_importers() does no such check. I

[issue21200] pkgutil.get_loader() fails on "__main__"

Eric Snow added the comment: I've opened #21211 to more directly address the find_loader() issue. -- ___ Python tracker <http://bugs.python.org/is

[issue20434] Process crashes if not enough memory to import module

Eric Snow added the comment: I was going to say we should consider changing the API of _PyBytes_Resize() and _PyString_Resize(). However, having looked at the two functions, I guess it makes sense. Looking at the patch, I'd argue that we still need to set the string to NULL in the

[issue20434] Process crashes if not enough memory to import module

Eric Snow added the comment: For example, in the patch binascii_b2a_uu() in Modules/binascii.c no longer sets rv to NULL even though in one of the _PyString_Resize() error cases rv is not automatically set to NULL. And simply setting rv to NULL would be backward-incompatible as well

[issue20434] Process crashes if not enough memory to import module

Eric Snow added the comment: Yeah, I missed the "*pv = 0;" line in the first error case. -- ___ Python tracker <http://bugs.python.org/issue20434> ___ ___

[issue20434] Process crashes if not enough memory to import module

Eric Snow added the comment: Okay from me, but Victor has a better idea of the string APIs. :) -- ___ Python tracker <http://bugs.python.org/issue20434> ___ ___

[issue21223] fix test_site/test_startup_imports when some of the extensions are built as builtins

Eric Snow added the comment: Looks good to me. This should not impact the standard build, but is useful for alternate builds. Does something similar need to happen to also exclude frozen modules? -- nosy: +brett.cannon, ncoghlan ___ Python

[issue21235] importlib's spec module create algorithm is not exposed

Eric Snow added the comment: I agree that this is something we need to address in 3.5. Adding this to 3.4 won't be an option since it would require a new feature. However, Loader.load_module() is only deprecated (and won't be removed in 3.X), so the current approach will still wor

[issue21240] Add an abstactmethod directive to the Python ReST domain

New submission from Eric Snow: I'd like to be able to mark abstract methods in the docs more explicitly and have their presentation in the docs be more obvious. So I'd like to propose "abstractmethod" as a new directive to join the existing ones (classmethod, staticmeth

[issue21235] importlib's spec module create algorithm is not exposed

Eric Snow added the comment: I've opened up #21240 to address the the docs concern. Thanks for bringing it up. :) -- ___ Python tracker <http://bugs.python.org/is

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: The performance is still an issue in python 3. Attaching a patch for python 3, performance numbers are below. Measuring ndbm time for a falsey check on an open db with 100 entries. gdbm performance is similar. Before patch: db is not None: 6.9141387939453125e

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Uploading patch with minor test changes (dbm_bool_b.patch). Backwards compatibility note: Result of running bool(db) on a db that has been closed: Old: _dbm.error: DBM object has already been closed With patch: returns False instead of raising. I think this

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Make the changes backward compatible after getting input on possible problems from r.david.murray patch: dbm_bool_c.patch Now, the only change should be faster performance for bool(db). -- versions: +Python 3.5 Added file: http://bugs.python.org

[issue21211] pkgutil.find_loader() raises ImportError instead of returning None

Eric Snow added the comment: Ah, it's ValueError rather than ImportError that causes the problem. Regardless, handling it would be necessary. -- ___ Python tracker <http://bugs.python.org/is

[issue12916] Add inspect.splitdoc

Eric Snow added the comment: I agree with Éric that exposing splidoc publicly in the inspect module is the right thing. inspect already has other similar functions. If it doesn't land in inspect then the only other place that makes real sense to me would be a new module (docs

[issue21256] Sort keyword arguments in mock _format_call_signature

Eric Snow added the comment: Ordered kwargs anyone? :) -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue21256> ___ ___ Python-bugs-list mailin

[issue21254] PropertyMock refuses to raise AttributeErrror as a side effect

Eric Snow added the comment: Perhaps related to #1615? -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue21254> ___ ___ Python-bugs-list mailin

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: New patch with Pep 7 fix - no c++ // style comments. -Thanks johansen. -- Added file: http://bugs.python.org/file34916/dbm_bool_d.patch ___ Python tracker <http://bugs.python.org/issue2

[issue20309] Not all method descriptors are callable

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

[issue16484] pydoc generates invalid docs.python.org link for xml.etree.ElementTree and other modules

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

[issue19771] runpy should check ImportError.name before wrapping it

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

[issue21211] pkgutil.find_loader() raises ImportError instead of returning None

Eric Snow added the comment: On second thought, all modules (except __main__) must have both __spec__ and __loader__ set to their correct respective objects. So the current behavior is correct in that it exposes poorly formed modules. -- resolution: -> not a bug stage: test nee

[issue21200] pkgutil.get_loader() fails on "__main__"

Eric Snow added the comment: The change is pretty minor so I went ahead and pushed it. To be honest, we should consider deprecating both get_loader and find_loader. I'm just not going to worry about it right now. :) -- resolution: -> fixed stage: patch review -> reso

[issue21226] PyImport_ExecCodeModuleObject not setting module attributes

Eric Snow added the comment: Here's a (currently segfaulting) patch that demonstrates how I'd like to solve this. Feedback on the approach is welcome. :) When I get a chance I'll debug the segfault. -- assignee: -> eric.snow keywords: +patch stage: -> pa

[issue21313] Py_GetVersion() is broken when using mqueue and a long patch name

New submission from Eric Snow: Py_GetVersion() (in Python/getversion.c) builds the version string returned by sys.version: PyOS_snprintf(version, sizeof(version), "%.80s (%.80s) %.80s", PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler()); In turn, Py_GetBuildInfo() (

[issue21226] PyImport_ExecCodeModuleObject not setting module attributes

Eric Snow added the comment: Thanks, Benjamin. Here's an updated patch that passes all tests. It should be good to go. And yet again our zipimport implementation was a pain point. :( -- Added file: http://bugs.python.org/file34980/fix-PyImport_ExecCodeModuleObject

[issue21319] WindowsRegistryFinder never added to sys.meta_path

New submission from Eric Snow: For #14578 we added WindowsRegistryFinder to importlib and try adding it to sys.meta_path during bootstrap (see bd58c421057c). I happened to notice that in _install() in Lib/importlib/_bootstrap.py we check os.__name__. Shouldn't it be os.name? os.__name

[issue21319] WindowsRegistryFinder never added to sys.meta_path

Changes by Eric Snow : -- versions: +Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21319> ___ ___ Python-bugs-list mailin

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Thank you for the feedback. Sorry I didn't see your previous response until today. I will take a look and respond tonight. -- ___ Python tracker <http://bugs.python.org/i

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Hi Jesús, I believe the patch should have this behavior: a) If the database is closed, raise an exception. b) If database is empty, return False. c) If database has any entry, return True. Fast and simply checking if the database has at least a single record

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Also, I'm happy to allow the code to be ported to pybsddb. As long as it doesn't cause any problems with CPython licensing - and I can't think of any way it could. -- ___ Python tracker <http

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: I did try the suggestion to return Py_False, but that gives the wrong result since Py_False is not 0 and gets returned as Py_True. I looked for similar code, and this looks like the convention for handling "if obj". PyObject_IsTrue() is called on

[issue2159] dbmmodule inquiry function is performance prohibitive

Eric Olson added the comment: Hi, Thanks for finding those issues. I attached a new patch. a) Good find, I added the free() for gdbm. ndbm doesn't need free(). b) Added the error check. I don't know if a test can be made for this. If there was a common way to patch C libraries

[issue13742] Add a key parameter (like sorted) to heapq.merge

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

[issue17794] Add a key parameter to PriorityQueue

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

[issue1475692] replacing obj.__dict__ with a subclass of dict

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

[issue21226] PyImport_ExecCodeModuleObject not setting module attributes

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

[issue21415] Python __new__ method doc typo (it's a class and not a static method)

Eric Snow added the comment: FYI, __new__() is a staticmethod to accommodate subclassing. Several things that happen at instantiation-time (when __new__() is called), including memory allocation, are tied to the class that is passed in and may be different for subclasses. For example

[issue21499] test_importlib incorrectly relies on .__builtins__

New submission from Eric Snow: Per the docs*, a module's __builtins__ may be a module or a dict or even missing. However, test.test_importlib.test_api.ReloadTests checks __builtins__ as part of several tests. Instead, the tests should ignore __bulitins__. I'll push a patch in a m

[issue21499] test_importlib incorrectly relies on .__builtins__

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

[issue21500] Make use of the "load_tests" protocol in test_importlib packages

New submission from Eric Snow: Right now to run importlib tests you can do either of the following: ./python -m tests test_importlib ./python -m tests.test_importlib Both make use of the regrtest infrastructure. For test submodules the commands are similar: ./python -m tests

[issue19891] Exiting Python REPL prompt with user without home directory throws error in atexit._run_exitfuncs

Eric Ongerth added the comment: I'm getting the same PermissionError 13: Error in atexit._run_exitfuncs: PermissionError: [Errno 13] Permission denied My case is: I'm running Python 3.4.0 as a non-root user in a docker.io container built on ubuntu 14.04. This user was created

[issue21503] Use test_both() consistently throughout test_importlib

New submission from Eric Snow: test_importlib.util provides the test_both() function that facilitates testing both the frozen and source versions of importlib. The function helps to keep the tests more maintainable. However, the following test modules are not using test_both(): Lib/test

[issue21495] Sane default for logging config

Eric Snow added the comment: FWIW, I agree with Vinay. -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue21495> ___ ___ Python-bugs-list mailin

[issue21503] Use test_both() consistently throughout test_importlib

Eric Snow added the comment: > I don't love the formatting of the test_both() lines, but I think that one is > just an aesthetic thing that will never make people happy -- weird line > wrapping or really long lines -- so just leave it as-is in your patch. Yeah, I went with the f

[issue21503] Use test_both() consistently throughout test_importlib

Eric Snow added the comment: FWIW, this change was motivated by the importlib backport (I found some time to work on it). The import_importlib()/test_both() approach definitely makes backporting the tests easier (thanks for that). BTW, thanks for also consolidating the various test_importlib

[issue21503] Use test_both() consistently throughout test_importlib

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

[issue14710] pkgutil.get_loader is broken

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

[issue21553] Behaviour of modules depends on how they where imported

Eric Snow added the comment: This is a consequence of a script's directory getting prepended to sys.path. See issue #13475. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <http:

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: @Brett: Did those last two messages (and the patch) get on the wrong issue. The issue of module_from_spec() or the like seems somewhat orthogonal to a spec argument to ModuleType. Perhaps you meant issue #21436 or #21235? Otherwise, I have a few comments

[issue21577] Help for ImportError should show a more useful signature.

New submission from Eric Snow: Currently: __init__(self, /, *args, **kwargs) Proposed: __init__(self, /, *args, name=None, path=None, **kwargs) Even that is still a little vague, but at least it doesn't gloss over the kwonly args added in 3.3. -- components: Interpreter

[issue21578] Misleading error message when ImportError called with invalid keyword args

New submission from Eric Snow: >>> ImportError(spam='spam') Traceback (most recent call last): File "", line 1, in TypeError: ImportError does not take keyword arguments However, it *does* take keyword arguments: >>> ImportError(name='spam', p

[issue15767] add ModuleNotFoundError

Eric Snow added the comment: Any chance we could revive ModuleNotFoundError? It's nice to be able to distinguish between the failure to *find* the module during import from other uses of ImportError. I'd definitely expect it to work the way Guido explained. Basically only

[issue21436] Consider leaving importlib.abc.Loader.load_module()

Eric Snow added the comment: I'd rather see something like "load_from_spec()" added to importlib.util, a la issue #21235. -- ___ Python tracker <http://bugs.pyt

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: Okay, I didn't read closely enough. :) It may be worth updating the title. FWIW, the name "module_from_spec" confused me at first because my brain interpreted that as "load_from_spec". Keeping the name and purpose more focused might be

[issue21235] importlib's spec module create algorithm is not exposed

Eric Snow added the comment: How about this replacement for direct use of Loader.load_module(): # in importlib.util def load(spec_or_name, /, **kwargs): # or "load_from_spec" if isinstance(spec_or_name, str): name = spec_or_name if not kwargs: raise

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: tl;dr I'm okay with pulling the functions out of _SpecMethods (and dropping the class) but I'd prefer the distinct functions continue to exist as they are. Also, I still think updating the ModuleType signature is the way to go (given current use cases). :

[issue21235] importlib's spec module create algorithm is not exposed

Eric Snow added the comment: I'm just considering current usage: mod = loader.load_module(name) becomes: spec = spec_from_loader(name, loader) mod = load(spec) vs. mod = load(name, loader=loader) I guess I'm torn. I like how the former forces you to consider specs whe

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: I give. :) You've made good points about builtins and C implementations. Also, thinking about issue #21235 has changed my perspective a bit. As to _SpecMethods, I mean just drop the class and turn the methods into functions: * name: -> _spec_ (or

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: You're right that it doesn't have to be a one-line wrapper or anything more than an import-from in importlib.util. :) -- ___ Python tracker <http://bugs.python.o

[issue21578] Misleading error message when ImportError called with invalid keyword args

Eric Snow added the comment: Looks good to me. Thanks for doing this. If no one objects in the meantime, I'll commit this in a few days. -- assignee: -> eric.snow stage: patch review -> commit review ___ Python tracker <http://b

[issue1683368] object.__init__ shouldn't allow args/kwds

Eric Snow added the comment: > If you don't know enough about the base class you shouldn't be subclassing it. That's important when overriding any API in subclass and absolutely always essential when it comes to __new__ and __init__! That's something that isn't ver

[issue21607] results of `zip` are displayed as '

Eric Snow added the comment: It may be the correct behavior but that doesn't mean we cannot update the repr to be more informative. We've already done that for a number of types that previously used the default __repr__() implementation. So in the case, how hard would it be t

[issue21607] results of `zip` are displayed as '

Eric Snow added the comment: > "zip(, 0xb70c7cac>)" doesn't look more readable to me. Well, that seems more informative to me. Now you know that you're zipping together two list iterators. By "readable" do you mean shorter? In my opinion the size of a r

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: Yeah, it just looks too complicated to take the ModuleType signature approach, as much as I prefer it. :) I appreciate you taking a look though. -- ___ Python tracker <http://bugs.python.org/issue20

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: But that part is less of a concern since we don't need namespace packages before or during bootstrapping, and afterward we have access to interp->importlib. Or am I missing something? > which gets us back into the whole question of whether types should

[issue20383] Add a keyword-only spec argument to types.ModuleType

Eric Snow added the comment: Thanks for doing that Brett and for accommodating me. :) Also, the various little cleanups are much appreciated. -- ___ Python tracker <http://bugs.python.org/issue20

[issue21577] Help for ImportError should show a more useful signature.

Eric Snow added the comment: Yeah, I also noticed that about **kwargs, but only a little while later and didn't get around to making a note here. As to ArgumentClinic, I imagine that this could be fixed when ModuleType (in Objects/moduleobject.c) gets converted to use it. I don'

[issue21760] inspect documentation describes module type inaccurately

New submission from Eric Snow: In the documentation for the inspect module, the module type is described with just 2 of its potential 7 attributes. The language reference[2] and importlib docs[3] both provide an accurate list of module attributes. Furthermore, the description for __file__

[issue21760] inspect documentation describes module type inaccurately

Changes by Eric Snow : -- nosy: +brett.cannon, ncoghlan ___ Python tracker <http://bugs.python.org/issue21760> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21761] language reference describes the role of module.__file__ inaccurately

New submission from Eric Snow: The language reference [1] says: Ultimately, the loader is what makes use of __file__ and/or __cached__ This implies that loaders should use __file__ and __cached__ when loading a module. Instead loaders are meant to implement exec_module() and use the spec

[issue21761] language reference describes the role of module.__file__ inaccurately

Changes by Eric Snow : -- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch ___ Python tracker <http://bugs.python.org/i

[issue21762] update the import machinery to only use __spec__

New submission from Eric Snow: With PEP 451, Python 3.4 introduced module specs to encapsulate the module's import-related information, particularly for loading. While __loader__, __file__, and __cached__ are no longer used by the import machinery, in a few places it still uses __n

[issue21736] Add __file__ attribute to frozen modules

Eric Snow added the comment: __file__ is the filename from which the module *was* loaded (the inspect doc [1] should probably reflect that [2]). The import machinery only uses the module's __spec__ (origin, etc.). __file__ is set strictly as informational (and for backward-compatib

[issue21709] logging.__init__ assumes that __file__ is always set

Eric Snow added the comment: > addLevelName.__code__.co_filename Isn't __code__ implementation-specific? -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org

[issue17004] Expand zipimport to include other compression methods

Eric Snow added the comment: related: issue #17630 and issue #5950 -- nosy: +eric.snow ___ Python tracker <http://bugs.python.org/issue17004> ___ ___ Python-bug

[issue21751] Expand zipimport to support bzip2 and lzma

Eric Snow added the comment: related: issue #17630 -- ___ Python tracker <http://bugs.python.org/issue21751> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21762] update the import machinery to only use __spec__

Eric Snow added the comment: Thanks for clarifying. I remembered discussing it but couldn't recall the details. Documenting the exact semantics, use cases, and difference between spec and module attrs would be help. I'll look into updating the language reference when I have some

[issue21791] Proper return status of os.WNOHANG is not always (0, 0)

New submission from Eric Radman: The documentation for the WNOHANG flag (https://docs.python.org/3.4/library/os.html#os.WNOHANG) suggests that a return value of (0, 0) indicates success. This is not always true, the second value may contain a value even on success. On OpenBSD 5.5 this is an

[issue16408] zipfile.testzip() opens file but does not close it.

New submission from Eric Busboom: The zipfile.testzip() method will open each of the files in a zip archive, but does not close the files, resulting in a file descriptor leak. -- components: Library (Lib) messages: 174829 nosy: Eric.Busboom priority: normal severity: normal status

[issue16408] zipfile.testzip() opens file but does not close it.

Eric Busboom added the comment: I've tried just closing the ZipExtFile created in testzip, but that didn't actually close the file. It looks like ZipExtClose.close() also doesn't close the file descriptor, at least when the ZipFile is constructed on a filename. This code worked

[issue9974] tokenizer.untokenize not invariant with line continuations

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

[issue11957] re.sub confusion between count and flags args

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

[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT

Changes by Eric Snow : -- versions: +Python 3.4 -Python 3.1 ___ Python tracker <http://bugs.python.org/issue12082> ___ ___ Python-bugs-list mailing list Unsub

[issue13912] ImportError using __import__ and relative level 1

Eric Snow added the comment: Are you okay on this, Jason? -- status: open -> pending ___ Python tracker <http://bugs.python.org/issue13912> ___ ___ Python-

[issue14080] Sporadic test_imp failure

Eric Snow added the comment: Given that issue14657 wrapped up, I'm closing this issue too. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.

[issue11076] Iterable argparse Namespace

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

[issue812369] module shutdown procedure based on GC

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

[issue6386] importing yields unexpected results when initial script is a symbolic link

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

[issue15480] Drop TYPE_INT64 from marshal in Python 3.4

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

[issue16163] Wrong name in Lib/pkgutil.py:iter_importers

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

<    20   21   22   23   24   25   26   27   28   29   >