On Oct 29, 2019, at 15:05, Richard Vogel <mer...@gmx.net> wrote:
>
> Nevertheless, could Python cache that spec and cache also a checksum of whats
> coming out after resolveing the loader ?
>
Sure. In addition to sys.modules mapping names to modules you could have a
similar dict mapping specs to modules. It might require some minor changes to
specs, and I’m only about 80% sure specs have exactly the info needed in the
first place, but otherwise it seems like it would work.
I don’t think you need the checksum for anything, but let’s come back to that;
if you do, it’s obviously easy to add another dict, or change the first dict to
map specs to (checksum, module) pairs, or whatever.
If you’re not changing any existing behavior to rely on this, only adding new
behavior, that sounds feasible to me. But if you are changing existing behavior
in a way that relies on this, that would break backward compatibility. Most
obviously, any existing code that modifies sys.modules assumes that it doesn’t
have to modify anything else, so whatever it was trying to do will probably no
longer work. And other things currently guaranteed by the import system and
relied on by code would also probably break. So you’d need a really compelling
reason to force people to change all that code over the next 3 versions.
> So given that Python could recognize the case where you actually import
> something similiar with a different loader spec (for example the case where
> something in path is imported fully quallified and non fully qualified).
>
The point of the spec is that (I think) you’d get the same spec for importing
spam.eggs and also importing eggs when they’re both the same file (or zip
entry, or whatever).
And Python assumes that it doesn’t have to deal with module source changing in
the middle of a run, except when you go explicitly behind the importer’s back
(e.g., with importlib.reload).
So I think just the spec itself tells you whether two modules are “the same” in
the relevant sense. So you don’t need a checksum, or anything else, there.
Meanwhile, if two different modules happen to have identical checksums—say,
because a.py and b.py are both empty files—they’re still different things. So I
don’t think you _want_ a checksum either.
Also, checksum of what? It’s obvious what to checksum for a module defined by a
.py file (but you still have to work out how that gets cached with the .pyc
files), and probably not hard for a .so file, but what’s the checksum of
package directory? Or an extension module linked into the interpreter
executable? At the very least you’d have to come up with a checksum function
for each loader type (and require third-party loaders to do the same—breaking
all existing ones).
> Given that Python could spill out a warning that this happened (also in your
> circular case for example) and just do what it does now still.
>
This makes sense. If a spec is already in the new spec-to-module dict, but the
module’s qualified name doesn’t match the name we’re trying to import it as,
warn. I think this could be done in a single place in importlib and just work.
The backward compatibility problem wouldn’t affect as many things, and a
warning isn’t as bad as an error or different behavior—but still, I’m not sure
you could convince people that the benefit is worth that cost.
It’s worth looking at why similar warnings have been rejected for the circular
__main__ issue in the past (which I don’t remember).
> Then a import keyword extension like *import twin ~~~* would explicitly do
> what it does now anyways (Giving you the same thing in a different
> realization, so basically just removing the warning in that case) and *import
> union ~~~* which returns the same realization and removing the warning. This
> would force the user into knowing what they do and give the user the chance
> to see that such a thing happened and start thinking about what they actually
> wanted to do in the first place.
>
Well, new keywords need to jump a pretty high hurdle. Either this would break
all code that used twin or union as ordinary identifiers (including the builtin
set class), or they would have to be “contextual keywords” that are special
only in specific grammar contexts, which have a lot of problems of their own.
(For just one example, they make best-effort-pseudo-parser tools as used by
IDEs and indexers and code coloring scripts a lot more complicated.)
What if, instead of new syntax, this were just a pair or magic modules, where
you write `import twin.spam` or `from twin import spam`?
I’m not sure that actually covers all reasonable use cases. But if it does, I
think this would be doable (although not easy for someone who doesn’t already
know importlib pretty solidly). And, if so, it should be doable in a way that
can be written as a third-party library and packaged on PyPI and probably work
with all Python 3.4+. Then, if it gets lots of uptake from PyPI it would be a
lot easier to argue for adding it to the stdlib. Plus, there’d be a
ready-to-use backport for people who want to use the feature but don’t want to
require Python 3.10.
If it doesn’t cover everything, you could definitely implement spam =
twin.import('spam'), but that’s obviously not nearly as nice to use.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XBZHYFD76ZJQRBAVZXVE5KXFSVC7QCBB/
Code of Conduct: http://python.org/psf/codeofconduct/
