On 2020-01-20 5:13 p.m., Steven D'Aprano wrote:
Soni, you seem to be using Thunderbird as a mail client. As far as I remember from my time with Thunderbird, it allows, and makes it quite simple, to trim your quoting. There's no need to quote an entire 100 line message to add a single one sentence comment at the end: it is not nice to your readers to force them to scroll past paragraph after paragraph of text they have already read that isn't directly relevant to your reply.
I generally do that but I was frustrated and exhausted. That is, that may have been slightly passive-aggressive... Sorry.
I wrote:
* but using a special, implicit, version of import which calls importlib.resources.read_text rather than the standard import;
* leading to confusion when people try things like
f'{from math import pi}'
and get a surprising TypeError that math is not a package.
And Soni replied:
that pi is not a resource*
I certainly hope not! The error message should be the *direct* cause of the error. In this case, pi is not a resource because math is not a package, and so we should report that error.
Think about how you would fix the problem: before you can add a "pi" resource, you first have to make math a package. Likewise, if we wrote something like this:
f'{from blibble_dibble import pi}'
we ought to get something like:
ModuleNotFoundError: No module named 'blibble_dibble'
rather than waste the caller's time trying to diagnose why the import system can't see the resource "pi" when the actual problem is that the import system can't even see the package itself. (Perhaps it is not on the path, perhaps it is misspelled.)
f'{from math import pi}' ^ SyntaxError: invalid syntax (at compile-time) f'{from math import "pi"}' ResourceNotFoundError: No resource named 'pi' @ 'math'; 'math' is not a package (at runtime) 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. it helps show the users the parallels between the two - they both use the import machinery, they do similar things (and, they *do* do similar things - they both load stuff from a package!), etc. 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 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. 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. I think this would be a huge win for everyone.