<div class="gmail_quote">I think I pretty much agree with what you're saying, vis-a-vis it being a standalone project, with good documentation, bringing in a wide range of names from different packages.<br><br>I don't think it's a problem, though, to bring in something like pandas that isn't yet so widely used. It's a classic newcomer trap: you know you need this 'table' functionality (especially if you've used R, where it's built in), but how do you search for it? I spent a few months using my own (crap) implementation before I discovered other people had already done it much better. To my mind, this functionality just needs to be there, and if there's not yet a standard package to do it, we should pick the best available and promote it as the new standard.<br>

<br>I'll get in touch with the matplotlib guys, and look at setting up a repository for standalone pylab.<br><br>Thanks,<br>Thomas<br><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


* It should be removed from matplotlib.<br>
* The --pylab flag in IPython should do a "from pylab import *"<br>
* The community should create documentation for pylab that should i)<br>
be in addition to the existing documentation ii) focused on new users<br>
and iii) refer to the existing docs for further details.  The last<br>
thing we want is for users to have to try to figure out that<br>
pylab.ndarray is actually numpy.ndarray and then look the docs up for<br>
that.<br>
* The documentation should be created in a manner that will allow us<br>
to create IPython notebooks for each function/class that documents its<br>
usage and shows examples.  With the upcoming ReST cells in the IPython<br>
notebook this should not be difficult.<br>
* IPython should have an integrated, pretty and searchable way for<br>
users to browse the pylab documentation.  Mathematica's documentation<br>
is a worthy target in this respect.<br>
* The pylab namespace should be big.  It should include basically<br>
everything you get in Mathematica or Matlab.  The only thing we would<br>
have trouble including would be sympy, as it defines symbolic versions<br>
of many of the functions in numpy.  I don't see a way around that<br>
unless we wrote functions that were smart that could call numpy or<br>
sympy's version by inspecting their inputs.  But sympy is a very large<br>
project so I would probably vote to keep sympy out of the pylab<br>
namespace and have pylab focus on numerical rather than symbolic<br>
things.<br>
* At least starting out, pylab should focus only on<br>
numpy/scipy/matplotlib and over time should only include tools that<br>
are used community wide and recognized as "standard"  While I love<br>
Pandas, I don't think it has risen to that level yet.</blockquote></div><br>