Brett Cannon added the comment:
Giving Eric is polymorphic first argument to types.ModuleType() is going to be
tricky thanks to the fact that it is not hard-coded anywhere in the C code nor
documented that the first argument must be a string (the only way it might come
up is from
Brett Cannon added the comment:
Another issue with the polymorphic argument is that the module type is one of
those rare things written in C with keyword parameter support, so renaming the
'name' argument to 'name_or_spec' could potentially break code.
--
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 rep...@bugs.python.org
Brett Cannon added the comment:
And another complication is the compatibility hack to set loader when
submodule_search_locations is set but loader is not since _NamespaceLoader is
not exposed in C without importlib which gets us back into the whole question
of whether types should function
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
function
Roundup Robot added the comment:
New changeset b26d021081d2 by Brett Cannon in branch 'default':
Issue #20383: Introduce importlib.util.module_from_spec().
http://hg.python.org/cpython/rev/b26d021081d2
--
nosy: +python-dev
___
Python tracker
Brett Cannon added the comment:
After all the various revelations today about how much of a hassle and murky it
would be to get types.ModuleType to do what we were after, I went ahead and
kept importlib.util.module_from_spec(), but dropped the module argument bit. I
also deconstructed
Eric Snow added the comment:
Thanks for doing that Brett and for accommodating me. :) Also, the various
little cleanups are much appreciated.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20383
Nick Coghlan added the comment:
Another thing to keep in the back of your minds: one of my goals for PEP
432 is to make it possible to have a fully functional embedded interpreter
up and running *without* configuring the Python level import system. This
is the state the interpreter would be in
Brett Cannon added the comment:
Why do you want a one-liner wrapper for the functions for the public API when
they are exactly the same?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20383
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 rep...@bugs.python.org
http://bugs.python.org/issue20383
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 helpful. I have comments
Brett Cannon added the comment:
First, about breaking up _SpecMethods: that was entirely on purpose. =) I
honestly have found _SpecMethods a bit of a pain to work with because at every
place where I have a spec object and I need to operate on it I end up having to
wrap it and then call a
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). :)
First,
Brett Cannon added the comment:
I think we view the fundamentals of built-in types differently as well. =) A
module instance can exist without a spec no problem. As long as you don't pass
that module instance through some chunk of code that expects __spec__ -- or any
other attribute for that
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: name - _spec_name (or
Brett Cannon added the comment:
Nope, I commented where I meant to. I wanted a way to promote people to
**always** create modules with properly initialized attributes while also
dealing with the module creation dance at the same time. Otherwise it will
require expanding the API of
Nick Coghlan added the comment:
I'd ask Why not a class method?, but I already know the answer
(types.ModuleType is implemented in C, so it would be unnecessarily painful to
implement it that way).
Given that, the utility function approach sounds good to me.
--
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. :)
Brett Cannon added the comment:
Here is an implementation of importlib.util.module_from_spec(). With this it
makes PEP 451 conceptually work like:
spec = importlib.util.find_spec(name)
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module)
About the only other
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20383
___
Brett Cannon added the comment:
My current thinking on this it to introduce in importlib.util:
def module_from_spec(spec, module=None):
Create/initialize a module based on the provided spec.
If a module is provided then spec.loader.create_module()
will not be consulted.
Nick Coghlan added the comment:
No, the attribute level arguments won't go away - __name__ deliberately differs
from __spec__.name in some cases (notably in __main__), __path__ may be
manipulated after the module is loaded, and __name and __file__ are both used
too heavily within module code
Brett Cannon added the comment:
I can dream about getting rid of the attributes, but I doubt it would happen
any time soon, if at all. But we do need to make it easier to set __spec__ on a
new module than it currently is to help promote its use.
--
Eric Snow added the comment:
Sounds good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20383
___
___
Python-bugs-list mailing list
Raymond Hettinger added the comment:
Would allow for the name attribute to be optional
...
with the idea that sometime in the future we can
deprecate pulling attributes from a module directly
Is there any chance that this would ever happen?
The __name__ attribute has been around almost
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__.
--
Brett Cannon added the comment:
I envision making this happen would also allow for importlib to be updated to
rely on __spec__ when possible, with the idea that sometime in the future we
can deprecate pulling attributes from a module directly and shift to always
working from __spec__.
New submission from Brett Cannon:
Would allow for the name attribute to be optional since it can be grabbed from
the spec. Since having module.__spec__ set is now expected we should help
ensure that by supporting it in the constructor.
--
components: Library (Lib)
messages: 209100
29 matches
Mail list logo
