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
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
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
Eric Snow added the comment:
I've opened #21211 to more directly address the find_loader() issue.
--
___
Python tracker
<http://bugs.python.org/is
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
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
Eric Snow added the comment:
Yeah, I missed the "*pv = 0;" line in the first error case.
--
___
Python tracker
<http://bugs.python.org/issue20434>
___
___
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>
___
___
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
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
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
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
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
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
Eric Snow added the comment:
Ordered kwargs anyone? :)
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue21256>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
Perhaps related to #1615?
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue21254>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue20309>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue16484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue19771>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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() (
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
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
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
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13742>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17794>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue1475692>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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
Eric Snow added the comment:
FWIW, I agree with Vinay.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue21495>
___
___
Python-bugs-list mailin
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
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
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14710>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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
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
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
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
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
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
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
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). :
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
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
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
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
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
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
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
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
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
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
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'
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__
Changes by Eric Snow :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue21760>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Eric Snow :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/i
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
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
Eric Snow added the comment:
> addLevelName.__code__.co_filename
Isn't __code__ implementation-specific?
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org
Eric Snow added the comment:
related: issue #17630 and issue #5950
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17004>
___
___
Python-bug
Eric Snow added the comment:
related: issue #17630
--
___
Python tracker
<http://bugs.python.org/issue21751>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue9974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: -eric.snow
___
Python tracker
<http://bugs.python.org/issue11957>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
versions: +Python 3.4 -Python 3.1
___
Python tracker
<http://bugs.python.org/issue12082>
___
___
Python-bugs-list mailing list
Unsub
Eric Snow added the comment:
Are you okay on this, Jason?
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue13912>
___
___
Python-
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.
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue11076>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue812369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue6386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15480>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue16163>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue16392>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue5950>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14228>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue16421>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14803>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15223>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue12703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15272>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue9325>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue9914>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15376>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15358>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15577>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15031>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15751>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue11776>
___
___
Python-bugs-list mailing list
Unsubscribe:
1701 - 1800 of 2629 matches
Mail list logo