<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div id=":13g">
<div class="im">&gt; This is highly unlikely.  We are loathe to break backwards<br>
&gt; compatibility, and this would be *major* breakage.  It&#39;s easier and<br>
&gt; less confusing to simply use a different name.<br>
<br>
</div>This makes sense.  Given this, I propose that the existing pylab<br>
module in matplotlib be developed into a more general namespace for<br>
this type of thing.  In that process care can be taken to not break<br>
backwards compat.  I think this is logical as pylab already does<br>
import * from a good number of things.</div></blockquote></div><br>I don&#39;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&#39;t break backwards compatibility. And then I think a different name is best to avoid confusion resulting from there being two pylabs.<br>

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

<br>I&#39;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&#39; isnull()/notnull() functions as methods to Series objects (columns), so there&#39;s less need to expose those functions in a flat namespace.<br>

<br>Given that we&#39;re going to be importing the major namespaces, I don&#39;t think newcomers will find it too difficult to type &quot;io.read_csv(&#39;myfile.csv&#39;)&quot;, versus the equivalent without io. The key, as Satrajit says, is that there&#39;s some way to find out about these functions. I don&#39;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&#39;m proposing is documentation - doing the namespace(s) will be relatively easy once we decide on the structure.<br>

<br>Thanks,<br>Thomas<br>