3 ms·
That’s because it’s a module within the PIL module, not an attribute of PIL. But that doesn’t really have anything to do with the original comment; that’s a dif
by woodruffw 2y ago
That’s because it’s a module within the PIL module, not an attribute of PIL. But that doesn’t really have anything to do with the original comment; that’s a different quirk of Python’s import machinery.
(Understanding the difference between packages, module hierarchies, and module attributes is table stakes for architecting a large Python package correctly. PIL almost certainly does this to prevent hard-to-debug circular imports elsewhere in their codebase.)
- Jasper_ 2y agoIt's a strange distinction, because the standard library sometimes eschews this. `os.path` is accessible through just `import os`, because they made os.py import it into the local namespace. I wish it was clearer sometimes what was a module, and what was an attribute in the core import syntax. `import foo; foo.bar` only breaks if it's a module, and `import foo.bar` only breaks if it's an attribute. If you do `from foo import bar`, the syntax works with both.
- ciupicri 2y agoJust because `os.path` is accessible through just `import os`, doesn't mean that you shouldn't import it explicitly. As the Zen of Python says, explicit is better than implicit. After all it's documented separately at https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html If you see `os.path.basename` what could `os.path` be? It would be a module most of the time because it's written with lowercase. `itertools.chain.from_iterable` [1] would be a notable exception. [1]: https://docs.python.org/3/library/itertools.html#itertools.chain.from_iterable https://docs.python.org/3/library/itertools.html#itertools.c...