[IPython-dev] Flat is better than nested

[Aaron Meurer]

Actually, that commit just lives in one of Mateusz's development
branches, so we haven't deployed it yet. I didn't time it either. I
suppose any kind of function decoration will make import times a
little slower, though whether or not it will be significant is
unclear.

I'm not entirely clear on the difference, but it seems that the common
idiom for __init__.py is something like

__all__ = []

import submodule
__all__.extend(submodule.__all__)

Adding new submodules is a lot less common than adding new functions
or classes, so doing things manually there should not be too bad. This
also lets you finely control whether you need to do "from IPython
import something" or "from IPython.submodule import something" or
"from IPython.submodule.submodule import something" for each
submodule.

Aaron Meurer

On Sun, May 19, 2013 at 2:39 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> mmh, that actually looks very cool.  I like how it also makes reading
> the source very clear and simple.  I only have a couple of questions:
>
> - did you ever measure the impact on import times?  IPython is kind of
> a monster already, and I always worry about making import times worse.
>
> - for nested packages, I guess you still need to collect from
> subpackages in `__init__`.  But with this approach, it seems like one
> could then in the proper container `__init__` do a few `from subpak1
> import *; from subpak2 import *;`, etc.  This would pull the `__all__`
> lists from all these guys.
>
> I also like that, by marking things explicitly in the source at the
> location of definition, it will encourage people to do an even better
> job at documenting those functions; anything marked @public should
> really have a good docstring...
>
> Thanks!
>
> f
>
> On Sun, May 19, 2013 at 10:29 AM, Aaron Meurer <asmeurer at gmail.com> wrote:
>> One thing you can try to make __all__ a little more manageable is to create
>> a decorator @importable that automatically adds a class or function to
>> __all__.
>>
>> See for example
>> https://github.com/mattpap/sympy/commit/aa37bc12f43d603a4c17e6765a9706d92b95526f.
>>
>> Aaron Meurer
>>
>>
>> On Sun, May 19, 2013 at 11:19 AM, Carlos Córdoba <ccordoba12 at gmail.com>
>> wrote:
>>>
>>> Hi Fernando,
>>>
>>> I'll talk to Pierre and the other members of our team to see if we can
>>> come up with a sensible PR. Just adding _all__ would be a real gain for
>>> us.
>>>
>>> Cheers,
>>> Carlos
>>>
>>> El 17/05/13 17:16, Fernando Perez escribió:
>>> > Hi Carlos,
>>> >
>>> > On Fri, May 17, 2013 at 12:51 PM, Carlos Córdoba <ccordoba12 at gmail.com>
>>> > wrote:
>>> >> Ok, thanks for the answer, that makes more sense (although I don't
>>> >> agree
>>> >> with making such changes so far ahead in time).
>>> >>
>>> >> But what about my proposal of an __all__ attribute? That would make
>>> >> IPython consumer lives much easier and pleasant.
>>> > Yes, that's something we actually need to work on and that's been on
>>> > my radar for a long time: exposing for some of the main packages a bit
>>> > of interface in the main __init__ file.
>>> >
>>> > BTW, it's worth noting that the Qt code in IPython is very much in
>>> > need of engineering love... You guys and Enthought are the main
>>> > stakeholders in there, but there's not a ton of activity.
>>> >
>>> > The reality is that it's a bit of a liability to have a complex code
>>> > like that where the most active core IPython team isn't really using
>>> > it.  So if you see architectural cleanups that you can make, by all
>>> > means dig into the code.  I'm sure things will be better for everyone
>>> > involved if that part of the code gains some more active
>>> > maintainership.
>>> >
>>> > Cheers,
>>> >
>>> > f
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev