On 28 April 2018 at 02:18, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On the plus side, it means one less thing for programmers to do.  On
the minus side, I find the imports at the top of the file to be a nice
catalog of external dependencies.  Implicitly importing submodules
would break that.

The idea might be not as useful since the programmer would have to use
the fully qualified name (relative to the "top-level" package).  So
why not just put that in the import statement?

I'm mainly thinking of it in terms of inadvertently breaking abstraction layers. Right now, implementation decisions of third-party package authors get exposed to end users, as the question of whether or not a submodule gets eagerly imported by the parent module, or explicitly configured as a lazy import, is exposed to end users:

Parent package eagerly imports submodules: no explicit submodule import needed, just import the parent package
Parent package explicitly sets up a lazy submodule import: no explicit submodule import needed, just import the parent package
Parent package doesn't do either: possible AttributeError at time of use depending on whether or not you or someone else has previously run "import package.submodule" (or an equivalent)

The current attribute error is cryptic (and not always raised if some other module has already done the import!), so trying the submodule import implicitly would also provide an opportunity to customise the way the failure is reported.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia