On Jan 20, 2020, at 16:17, Soni L. <[email protected]> wrote: > > in any case the whole thing I'm arguing for in this thread, is to *draw > parallels* between module imports and resource imports. ppl talk about it > like it would be "confusingly similar" but I argue that it would be > *non-confusingly* similar instead. because the whole point of this syntax > *is* to look similar to the other syntax.
But it doesn’t work like the other syntax. The difference between using an import statement and using an importlib function when importing packages or modules or objects out of modules is that the statement binds things to names, while the function returns values. You want something that returns values, but you want it to look like the statement instead of like the function. That’s the false parallel you’re drawing. The fact that it leads you to do other things like create a statement that has a value and can be used in places that statements can’t be used and so on, that’s all secondary and follows from the root problem. This is why at least two people have suggested an import hook. It would allow you to write `from spam import eggs` to get the contents of spam.eggs bound to a variable named eggs (and cached, unless you deliberately circumvent that). It would be using the import statement as an import statement. I even suggested that if you put the import hook on PyPI and show people using it, you could propose adding it to Python, but you’ve still ignored it. The other thing worth noting is that the function allows you to do more. For example, if I want to read a PNG file, I don’t want to import it as bytes and wrap it in a BytesIO to pass to my image library, I want to get an open file object to pass to my image library. Or, even better, I want to wrap that in a function that gets an open file object, passes it to my image library, closes it, and returns the image object. That’s a two-liner with the function (and it would be easy to add to an import hook), but it couldn’t be done with your syntax. > I *want* the parallels to be drawn. I *want* the similarities to be > highlighted. this is where using importlib.resources breaks down because it > *doesn't* highlight those similarities. how many ppl know about > importlib.resources? I How many people know about any new feature? How many people would know about your new import expression if they had to get Python 3.10 or later and use a future directive until 3.12 to use it? Not many. People have been using pkgutil or setuptools for decades to do this. The next time they look up the resources docs in the PyPA documentation and it tells them to consider using importlib instead if they can require newer Python, they will learn about it. Of course old blogs, StackOverflow answers, etc. will take longer to mention it. But all of this would be the same with your proposal, except that it would all start with 3.10 instead of 3.7, and it would come with more caveats. > still have my (large-ish) strings (such as built-in HTML and TOML templates, > etc) shoved straight into my code instead of loading them with > importlib.resources, altho that's mostly because I haven't refactored it to > use importlib.resources. You’d have to refactor it the same way to use your new import expression. And I don’t know why you haven’t been using pkgutil/setuptools resources to do this since the start. Presumably you never read the PyPA documentation that recommended them. Which means presumably you wouldn’t have read newer PyPA documentation that recommended something new. So you’d discover it after the fact and then have to refactor. > The python tutorial doesn't even touch on managing and importing resources. > If it had its own syntax, the tutorial would be forced to talk about it. No it wouldn’t. There’s all kinds of stuff in Python that the tutorial doesn’t cover—even syntax like yield from, yield expressions, async/await, etc. It doesn’t explain namespace packages. It doesn’t explain how to properly structure a package, how to write a setup.py to use with setuptools, etc. It’s just meant to get you started with the language, give you a tour of highlights of other features, and point you to other documentation, not to cover everything you could possibly want to do. And even if everyone agrees that the tutorial should cover some new feature X, that doesn’t happen automatically, someone has to write the new docs and for them into the existing structure and shepherd it through all the annoying bikeshedding. (Look at the venv feature for a good example; I’m pretty sure that included adding a new section to the tutorial, which meant reorganizing the chapter on pip, and Included an argument about where it should go and whether to include forward references to it earlier in the tutorial, etc. Maybe something similar should have been done with the importlib.resources change, but nobody volunteered to do it, much less argued to convince everyone, so nothing changed in the tutorial. As with most changes in Python. In this case, the relevant other documentation is “Distributing Python Modules”. Which is not called out explicitly anywhere, and unfortunately named for anyone who finished the tutorial and wants to learn how to do more complicated stuff with packages if that complicated stuff doesn’t include putting them on PyPI. And, even if you find it, it’s just a stripped-down skeleton of the obsolete docs with pointers to the external PyPA docs. Probably it would be better if the tutorial chapter on modules referenced the PyPA docs and gave some hints of the kinds of things you can do. But it doesn’t. I think a bigger hole in the documentation is that there’s no howto on import hooks, with the result that very few people know how to write them and everyone thinks it’s really difficult. And the fact that most of the examples you can find out there are meant to work with all of 2.7 and early 3.x and modern 3.x (which actually is hard…) doesn’t help. The only docs that explain the point of import hooks are in the PEP that added the 2.x feature, and even if you find that, trying to figure out how to do it in modern Python just by reading through the library reference docs for the helper tools is a nightmare. In a world with ideal docs, you would have already guessed that you could do what you want with an import hook, written it, published it to PyPI, and then come here with either a proposal to add your import hook (which is now being used in the wild) to the standard import system—or an explanation of the unsolveable flaws in that approach and how a new language feature could solve them (a la the @ operator proposal), instead of a vague proposal to “use the import system” without clearly specifying what that means and without an answer to why you can’t just do it with the existing syntax beyond just “if there were syntactic sugar for this function it would be easier”, which is true for every function in the language. And, once one or the other was done, the PyPA docs and maybe even the tutorial in that ideal world would have already included an introduction to importlib.resources, so all you’d have to do is update them to show the simpler new way. In the real world, I still think that’s the right approach to take. It’s much more of a pain, but that doesn’t mean there’s a better answer that isn’t a pain. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QOF4P4ZMLGGFFJ4OYUWIPJ23ES4662L4/ Code of Conduct: http://python.org/psf/codeofconduct/
