[IPython-dev] Flat is better than nested

Fernando Perez fperez.net at gmail.com
Sun May 19 16:39:48 EDT 2013


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
>



More information about the IPython-dev mailing list