[IPython-dev] Flat is better than nested

[Aaron Meurer]

On a somewhat unrelated note, if __all__ is supposed to represent
those things in a module that are public API, would it make sense for
IPython's tab completer to respect this, so that

from module import <TAB>

only showed those things in module.__all__, if module.__all__ is
defined?  To me, that would go a long way to solidifying this
definition of __all__ in people's minds, or at least people like me
who use IPython to prototype code that uses library code.

Aaron Meurer

On Mon, May 20, 2013 at 11:00 AM, Carlos Córdoba <ccordoba12 at gmail.com> wrote:
> Hi,
>
> @Aaron: A @public decorator seems really cool, it makes look code really
> neat! I'll investigate how to include it in our PR.
>
> @Trevor: I think you are missing the point: these changes are not meant for
> regular users but for projects that are using IPython as a library. The idea
> is to put in __all__ the main pieces of qtconsole (not only
> RichIPythonWidget, but also QtKernelManager, QtKernelClient, etc) to tell
> those projects what elements they need to rely on to build a customized
> frontend.
>
> Cheers,
> Carlos
>
> El 20/05/13 11:26, W. Trevor King escribió:
>
> On Fri, May 17, 2013 at 11:19:47AM -0500, Carlos Córdoba wrote:
>
> For us in Spyder it would be better to be able to import things like
> RichIPythonWidget as
>
> from IPython.frontend.qt import RichIPythonWidget
>
> instead of
>
> from IPython.qt.console.rich_ipython_widget import RichIPythonWidget
>
> because even without "frontend" there are four levels of nested modules
> to reach one of the most essential pieces of that frontend.
>
> So why not add an __all__ attribute to each frontend instead?
>
> I've just been skimming this thread, but I'd caution against namespace
> squashing for scripting things (not very DRY).  If users are calling
> RichIPythonWidget from their IPython session, then providing a
> shortcut namespace is fine (à la Matplotlib's pylab [1]), but having
> multiple script-oriented locations is just confusing.  In this case,
> it might be best to have:
>
>   from ._rich_ipython_widget import RichIPythonWidget
>
> in IPython.qt.console (or IPython.qt?), which all consumers have to
> use instead of importing the (now private) rich_ipython_widget module
> directly.
>
> Cheers,
> Trevor
>
> [1]:
> http://matplotlib.org/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related
>
>
>
> _______________________________________________
> 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
>