<div class="gmail_quote">I think I pretty much agree with what you&#39;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&#39;t think it&#39;s a problem, though, to bring in something like pandas that isn&#39;t yet so widely used. It&#39;s a classic newcomer trap: you know you need this &#39;table&#39; functionality (especially if you&#39;ve used R, where it&#39;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&#39;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&#39;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 &quot;from pylab import *&quot;<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&#39;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&#39;t see a way around that<br>
unless we wrote functions that were smart that could call numpy or<br>
sympy&#39;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 &quot;standard&quot;  While I love<br>
Pandas, I don&#39;t think it has risen to that level yet.</blockquote></div><br>