[IPython-dev] Flat is better than nested

Mateusz Paprocki mattpap at gmail.com
Sun May 19 19:21:44 EDT 2013


Hi,

On 19 May 2013 22:39, 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.
>

Assuming that decorator application has the same cost as function call,
then:

In [1]: from sympy.utilities.decorator import public

In [2]: def f(): pass

In [3]: %timeit public(f);
1000000 loops, best of 3: 355 ns per loop

In [4]: class F(object): pass

In [5]: %timeit public(F);
1000000 loops, best of 3: 660 ns per loop

(on 3.4 GHz i7).

For ~100 @public cases (in sympy.polys) our bin/test_import tool confirms
that there is no visible speed impact.

Current implementation is rather rough, so there may be a way to improve
speed (I didn't explore other possible approaches, e.g. using inspect).

- 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
>

Mateusz


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130520/6c2af1d2/attachment.html>


More information about the IPython-dev mailing list