Policy for import of submodules

[Tony Yu]

On Tue, Jan 29, 2013 at 10:05 PM, Juan Nunez-Iglesias <jni.soma at gmail.com>wrote:

> Hi,
>
> Does scikit-image have a specific policy for how imports should work? For
> example, as far as I know, numpy currently imports everything into the np
> namespace with:
>
> import numpy as np
>
>
> However, the following raises an error, even though the import statement
> works fine:
>
> import skimage as skim
> coins = skim.data.coins()
>
> giving the error:
>
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)
> <ipython-input-3-0ce27ef61295> in <module>()
> ----> 1 coins = skim.data.coins()
>
> AttributeError: 'module' object has no attribute 'data'
>
>
> But some things *are* in the top-level namespace. The following works
> fine:
>
> import skimage as skimfrom skimage import data
> coins = data.coins()
> coins = skim.img_as_float(coins)
>
>
> So my question is, is this behaviour by design, or should there be nothing
> at all in the top-level, or should everything be imported?
>
>
I tend to agree that it should be one or the other (with the exception of
the standard metadata at the top-level).

The argument against importing everything is that it can lead to slow
import times (see, numpy for
example<http://numpy-discussion.10968.n7.nabble.com/quot-import-numpy-quot-is-slow-td13862.html>),
even when you're only using a small subset of the package. While this time
may not be too severe now, the hope is that scikit-image will grow
ever-more functionality, which would slow import times.

I'm in favor of moving the functionality out of the top level. I think the
only thing that would need to be moved out would be the converters in
`skimage.util.dtype`. There should be a shorter path to access those
functions, though. Side note: I'm not a huge fan of `util` (I would have
thought `utils`), but that's a minor point.

And of course, if others agree, this would need to be phased in over
time---probably with a couple of releases raising deprecation warnings when
trying to access those functions at the top level.

Also, this would wait until after the release of 0.8.

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20130129/57f2efb1/attachment.html>