On 2020-01-20 12:48 a.m., Andrew Barnert wrote:
On Jan 19, 2020, at 15:10, Soni L. <fakedme...@gmail.com> wrote:
>
> We have importlib. We have importlib.resources. We can import modules. We cannot (yet) import resources using the same-ish module import machinery.
First, do you know about setuptools resources? It’s not exactly what you’re
looking for, but it has advantages like working automatically for packages
installed as zip files, and can be easily extended to do things like i18n- or
platform-driven different versions of files, and it works with existing Python.
Meanwhile, if that’s not appropriate or not good enough somehow, couldn’t you
do what you want without any new syntax? For example, if you write an import
hook that registers a meta for .txt files that just returns a string instead of
a module object, wouldn’t `from foo.bar import spam` be able to find
foo/bar/spam.txt and bind its contents to spam (and also work with zip files,
combined namespace packages,, relative imports, `import foo.bar.spam` and then
accessing it as a member of foo.bar, etc.)? And you could likewise register
something like `.dat` for binary files, or a whole range of extensions for PNG
and OGG and so on, or even a meta that uses file magic to decide whether to
import as text or bytes. (Or the hook could even be hookable so your app just
says .png or MIME type image/png imports as a PIL.Image and then just imports
PNG resource files.)
Of course that’s obviously “messing with importlib”, but it’s something you’d
only have to do once, not over and over for each project. You could put it on
PyPI and get real life experience showing how it makes code nicer than using
setuptools resources and then have a much more compelling case for adding it to
Python. And of course it would work as a backport for earlier versions of
Python.
What's wrong with the existing import machinery and why does that mean I
need setuptools?
> It would be nice if we could.
>
> I'm thinking of something like:
>
> from foo.bar import resources "foo.txt" as foo, "bar.txt" as bar # string imports
> from foo.bar import bresources "foo.txt" as bfoo, "bar.txt" as bbar # bytes
imports
I’m pretty sure there’s a lot of code out there that uses the name “resources”,
so this would be a backward compatibility hit that would probably require the
usual 4-1/2 year deprecation and/or future transition.
But do you even need a keyword there? In the current syntax, a quoted string
after import is an error, so why not just change that to always mean a
(resource) filename without needing a keyword marker? I suppose that doesn’t
handle the bytes case, but there might be a better solution there.
Contextual keywords. If not followed by a string, just "fallback" to the
old stuff. (The lookahead here is not a problem and you can trivially
workaround it in the parser by making the contextual keyword path
include (part of) the existing path as a continuation.)
> or maybe:
>
> foo = f"{from foo.bar import 'foo.txt'}" # string imports
> bbar = fb"{from foo.bar import 'bar.txt'}" # bytes imports
This version would require turning import from a statement into an expression,
which seems like a pretty big change.
It would not. Equivalently, ''!r isn't an expression and yet you can do
f"{''!r}", because it's special syntax of fstrings.
And it would be a very weird expression that has side effects but no value when
you import a target, but a value and no side effects when you import a string,
and… I’m not even sure what when you import a list of strings, much less a
mixed list of strings and targets.
You don't even know what it would be (see above) so how am I supposed to
make sense of the rest of this argument?
And why does it even need to be a statement? If you just want to get a value;
what’s wrong with the function call syntax (a la setuptools)? The only reason
import has to be special syntax in the first place is that it does stuff like
adding bindings into the outer namespace, and your proposal (in this second
version) doesn’t need that.
Don't forget caching. And don't forget to (re-)read up on how it
actually works before making claims about it. And the point is that you
shouldn't have to import stuff to be able to import stuff, even if the
latter stuff is resources. It should be built into the language just
like importing modules is built into the language.
_______________________________________________
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/KQ5PKBCB4FSXW464O3PYZU7J5QGXMSTB/
Code of Conduct: http://python.org/psf/codeofconduct/
