[IPython-dev] Integrating pandas into pylab

Thomas Kluyver takowl@gmail....
Wed Oct 26 13:38:05 CDT 2011


>
> > This is highly unlikely.  We are loathe to break backwards
> > compatibility, and this would be *major* breakage.  It's easier and
> > less confusing to simply use a different name.
>
> This makes sense.  Given this, I propose that the existing pylab
> module in matplotlib be developed into a more general namespace for
> this type of thing.  In that process care can be taken to not break
> backwards compat.  I think this is logical as pylab already does
> import * from a good number of things.
>

I don't think matplotlib is really a natural home for a combined interface
to a variety of libraries. It seems more natural to maintain it as a
distinct thing. Also, as the discussion is showing, we might not want to
keep the same structure as mpl.pylab - in which case it will need to be
separate so we don't break backwards compatibility. And then I think a
different name is best to avoid confusion resulting from there being two
pylabs.

With regards to the flat vs. structured namespace debate, I wonder if there
is a middle ground - exposing some key functions (like plot()) in the flat
namespace, and having others in (sensibly named) namespaces. However, then
we need to somehow decide which functions merit being directly available.

I've not used matlab or mathematica, but compared to R, we have the
advantage of methods, which are relatively easy to discover via tab
completion. For instance, I added Pandas' isnull()/notnull() functions as
methods to Series objects (columns), so there's less need to expose those
functions in a flat namespace.

Given that we're going to be importing the major namespaces, I don't think
newcomers will find it too difficult to type "io.read_csv('myfile.csv')",
versus the equivalent without io. The key, as Satrajit says, is that there's
some way to find out about these functions. I don't think this necessarily
needs to be in-program: searchable, readable online docs in a single
location would be a good start. In fact, I think 99% of the work for what
I'm proposing is documentation - doing the namespace(s) will be relatively
easy once we decide on the structure.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20111026/2ac75c60/attachment.html 


More information about the IPython-dev mailing list