matplotlib-users

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Christopher B. <Chr...@no...>]

Keir Mierle wrote:
> p.s. This is part of my plan to kick off http://scipy.org/PyLab

Great Plan, and I think kicking it off with better docstrings is a good 
start.

One comment, from your Wiki Page:

"""
I feel strongly that the correct way to import the entire core PyLab API 
should be via

from pylab import *
"""

No, no, no, no NO!

see, I feel strongly too ;-).

You are trying to build something that is better than MATLAB. The one 
way you are almost guaranteed to achieve that is that it is built on the 
Python language, which is much more powerful and flexible than Matlab, 
but you know that already.

However, you are tossing away a lot of the advantage if you don't keep 
the focus on being pythonic, and that means, in this case:

"Namespaces are one honking great idea -- let's do more of those!"

note, NOT "fewer of those"

numpy + matplotlib + scipy

is a LOT  of functionality. It should not be all in the same namespace. 
It's really not that hard to do something like:

import matplotlib as plot
import numpy as N
import Scipy.whatever as whatever.

I think it's very helpful to keep things clean and separated. Sure, you 
can work to remove duplication an name clashes among these three 
packages, but what if the user decides they also need PIL, or PyGame, or 
PyNetCDF, etc, etc. One of the real powers of Python is that it has 
broad use, and that there is a module for just about everything you need 
to do, all maintained by others -- you are guaranteed name clashes if 
you don't use namespaces -- that's what they are for.

Note python itself. A lot of common functionality is in modules you need 
to import: sys, os, sys.path, string (though string methods remove much 
of that need) This is a GOOD model!

Also, I'd really like to see far more use of an OO approach in 
matplotlib use (and maybe scipy -- I haven't used much of it). If you 
note, numpy has made lots of things ndarray methods that were functions 
in Numeric -- this makes NOT using "import *" much cleaner.

In short: I think your goals are great, most of your approach is good, 
but please: Keep PyLab pythonic -- don't try to make it more like 
matlab, or fortran, or any other language -- your users will thank you 
for it later!

See recent discussions on the matplotlib list about this topic. I think 
even John is shifting toward wanting more use of the OO interface.

-Chris
















-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[David L G. <Dav...@no...>]

One more namespace "pro" (on point, since you're concerned w/ 
docstrings, and thus, presumably, usability): indicating the namespace 
makes your code more self-documenting (my favorite aspect of it).

DG

Christopher Barker wrote:
> Keir Mierle wrote:
>   
>> p.s. This is part of my plan to kick off http://scipy.org/PyLab
>>     
>
> Great Plan, and I think kicking it off with better docstrings is a good 
> start.
>
> One comment, from your Wiki Page:
>
> """
> I feel strongly that the correct way to import the entire core PyLab API 
> should be via
>
> from pylab import *
> """
>
> No, no, no, no NO!
>
> see, I feel strongly too ;-).
>
> You are trying to build something that is better than MATLAB. The one 
> way you are almost guaranteed to achieve that is that it is built on the 
> Python language, which is much more powerful and flexible than Matlab, 
> but you know that already.
>
> However, you are tossing away a lot of the advantage if you don't keep 
> the focus on being pythonic, and that means, in this case:
>
> "Namespaces are one honking great idea -- let's do more of those!"
>
> note, NOT "fewer of those"
>
> numpy + matplotlib + scipy
>
> is a LOT  of functionality. It should not be all in the same namespace. 
> It's really not that hard to do something like:
>
> import matplotlib as plot
> import numpy as N
> import Scipy.whatever as whatever.
>
> I think it's very helpful to keep things clean and separated. Sure, you 
> can work to remove duplication an name clashes among these three 
> packages, but what if the user decides they also need PIL, or PyGame, or 
> PyNetCDF, etc, etc. One of the real powers of Python is that it has 
> broad use, and that there is a module for just about everything you need 
> to do, all maintained by others -- you are guaranteed name clashes if 
> you don't use namespaces -- that's what they are for.
>
> Note python itself. A lot of common functionality is in modules you need 
> to import: sys, os, sys.path, string (though string methods remove much 
> of that need) This is a GOOD model!
>
> Also, I'd really like to see far more use of an OO approach in 
> matplotlib use (and maybe scipy -- I haven't used much of it). If you 
> note, numpy has made lots of things ndarray methods that were functions 
> in Numeric -- this makes NOT using "import *" much cleaner.
>
> In short: I think your goals are great, most of your approach is good, 
> but please: Keep PyLab pythonic -- don't try to make it more like 
> matlab, or fortran, or any other language -- your users will thank you 
> for it later!
>
> See recent discussions on the matplotlib list about this topic. I think 
> even John is shifting toward wanting more use of the OO interface.
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   


-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

[Matplotlib-users] PS: Re: [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[David L G. <Dav...@no...>]

One more thing: knowing Chris, I *think* that he wasn't saying that you 
should somehow *oblige* the coder to use namespace prefices, rather, 
don't do anything that would make it harder or less efficient to do so, 
right Chris?

DG

Christopher Barker wrote:
> Keir Mierle wrote:
>   
>> p.s. This is part of my plan to kick off http://scipy.org/PyLab
>>     
>
> Great Plan, and I think kicking it off with better docstrings is a good 
> start.
>
> One comment, from your Wiki Page:
>
> """
> I feel strongly that the correct way to import the entire core PyLab API 
> should be via
>
> from pylab import *
> """
>
> No, no, no, no NO!
>
> see, I feel strongly too ;-).
>
> You are trying to build something that is better than MATLAB. The one 
> way you are almost guaranteed to achieve that is that it is built on the 
> Python language, which is much more powerful and flexible than Matlab, 
> but you know that already.
>
> However, you are tossing away a lot of the advantage if you don't keep 
> the focus on being pythonic, and that means, in this case:
>
> "Namespaces are one honking great idea -- let's do more of those!"
>
> note, NOT "fewer of those"
>
> numpy + matplotlib + scipy
>
> is a LOT  of functionality. It should not be all in the same namespace. 
> It's really not that hard to do something like:
>
> import matplotlib as plot
> import numpy as N
> import Scipy.whatever as whatever.
>
> I think it's very helpful to keep things clean and separated. Sure, you 
> can work to remove duplication an name clashes among these three 
> packages, but what if the user decides they also need PIL, or PyGame, or 
> PyNetCDF, etc, etc. One of the real powers of Python is that it has 
> broad use, and that there is a module for just about everything you need 
> to do, all maintained by others -- you are guaranteed name clashes if 
> you don't use namespaces -- that's what they are for.
>
> Note python itself. A lot of common functionality is in modules you need 
> to import: sys, os, sys.path, string (though string methods remove much 
> of that need) This is a GOOD model!
>
> Also, I'd really like to see far more use of an OO approach in 
> matplotlib use (and maybe scipy -- I haven't used much of it). If you 
> note, numpy has made lots of things ndarray methods that were functions 
> in Numeric -- this makes NOT using "import *" much cleaner.
>
> In short: I think your goals are great, most of your approach is good, 
> but please: Keep PyLab pythonic -- don't try to make it more like 
> matlab, or fortran, or any other language -- your users will thank you 
> for it later!
>
> See recent discussions on the matplotlib list about this topic. I think 
> even John is shifting toward wanting more use of the OO interface.
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   


-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Christopher B. <Chr...@no...>]

Keir Mierle wrote:
> I do not want to descend into a huge, time wasting discussion of this 
> which is not productive.

Well, it's been said before, and this isn't really the place for it, but 
it's quite critical to your project. Don't let any of this get in the 
way of improving docs strings, however!
> Note that I am not suggesting a recursive import of submodules.

What you appeared to support was that all of the matplotlib, numpy and 
scipy base namespaces be merged, and they should all be merged into the 
main namespace.

>> import matplotlib as plot
>> import numpy as N
>> import Scipy.whatever as whatever.
> 
> UGH. See, this is my issue. When I read someone else's code, they always 
> chose a different convention.

Good point, that is a bit of a pain. It would certainly be a good idea 
to standardize at least these three, and have them be imported by 
default in your environment (though I'm not sure about scipy -- numpy 
and matplotlib would be good)

> If we define the official way to use pylab as 'from pylab import *', 
> then these problems vanish.

and others arise. One is that you then have to make sure you don't' get 
any name clashes you don't want, so you end up with arange, so it won't 
clash with range. etc.

> Note that we must be *very* careful to export only 
> exactly the names which should be exported;

Then how do you get the others? "import *" and "import pylab"?

> Because it is always the case
> that I use numpy and pylab together.

I use numpy every day without pylab. And I use pylab occasionally 
without numpy, it accepts regular old lists for quick hacking.

This is a key point -- if all anyone does is use your mega-pylab, then 
you may be right, but let's not cripple people. Let them start using 
PyLab for matlab-like quickie coding, then decide to write a real app, 
and be able to start using wxPython without learning a bunch of new 
stuff, and having namespaces clash.

> Other non-core modules should be 
> treated as usual, where it is at the author's discretion for how to import them.

Everyone's idea of non-core is different

Even if you insist on joining numpy and plotting namespaces (they are 
both too big at the moment, if you ask me), please tell people to import 
it as:

import pylab

I think a consensus is building in the python community that you should 
NEVER use import *!

some history:

wxPython used to be commonly used as:

from wxpython import *

And the names were all: wxSomeName.

A few years back, the names were all changed to remove the wx, and we 
now all do:

import wx
this = wx.SomeName(...)

Numeric was designed to be used with "import *". Now many of the old 
Numeric functions are available as numpy methods, and more and more 
people are using some variation of:

import numpy as N

and fewer are using "import *"

Does anyone else have any other examples?

One more reason: more IDEs are providing auto-completion and module 
browsers. Smaller, more hierarchical namespaces are much better for 
this. I know if I'm looking for a number crunching or a plotting 
function -- make it easier to find them.

> I think Scott Meyer, a C++ luminary, said it best [1] when this heinous
> fragment of his code was posted in comp.lang.c++.moderated

namespaces are a new add-on to C++ -- it will be a good while before 
they are used right there!

> This is only for the core functionality. The scipy/numpy/matplotlib core 
> API becomes similar in importance to Python's __builtins__ for the PyLab
> environment.

 >>> len(dir(__builtins__))
129
>>> len(dir(pylab))
432

and __builtins__ is too big as it is. -- 31 of those are Exceptions, 
they should have their own namespace, if you ask me. Would it be that 
much harder to type

except Errors.Type:

than

except TypeError:

> I argue that Python's __builtins__ should be equivalent to PyLab's from 
> pylab
> import *, and that e.g. import sys corresponds to import linalg.

But then you have __builtins__ and pylab in the same namespace!

> Perhaps non-interactively; when using the system interactively the MATLAB
> interface is by far the best way to go. If someone proposes an oo interface
> which is as fast to type and as easy to understand as the MATLAB interface
> (i.e. to demo to my friends who came over to see what I'm talking about 
> when I
> say that PyLab is great) then I'm all ears.

Look for my (and other) posts about this for more detail, but a few points:

1) Don't break long-term productivity/useability so that the quicky 
demos are more impressive. Python's real strength over tools like Matlab 
shows up when projects get bigger.

2) There is nothing about an OO interface that is inherently harder to 
use, or even more typing, except perhaps a few extra dots.

3) There is some work to be done to bring the matplotlib OO interface up 
to its potential for interactive use, particularly the docs!

> Note that this discussion is early! I am waaaay not here yet; first step 
> is to fix the docstrings. 

Yes, enough said for now -- and I really appreciate your efforts to 
clean up the docstrings.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Matthew B. <mat...@gm...>]

Hi,

> I think a consensus is building in the python community that you should
> NEVER use import *!

Well, I have only been coding python for a few years, but I would say,
along with writing unit tests, the great importance of not using
import * is one of the secrets that you learn slowly and painfully
with experience.  Chris' point about the movement of big projects away
from that idiom is a very good one. It is convenient, but over time
you realize that the value of convenience is far outweighed by the
namespace mess and loss of clarity that results.

Best,

Matthew

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Barry W. <bar...@gm...>]

Perhaps we should consider two use cases: interactive use ala Matlab
and larger code bases. In the first case, being able to import * saves
a lot of typing and the namespace polution problem isn't a big deal.
The second use, obviously, benefits from avoiding import *.

Returning to the OP's questions, why couldn't both cases be helped by
creating a "meta-package" for numpy, scipy, and matplotlib? For the
sake of argument, lets call the package "plab". Existing code could be
affected by changing the individual packages, but a package that
essentially does

from pylab import *
from numpy import *
from scipy import *

would give a standard API that future code and interactive use could
use. Code could do
import plab

plab.plot() #etc.

and interactive use could do from plab import *.

Just a thought...

Barry

On 2/16/07, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> > I think a consensus is building in the python community that you should
> > NEVER use import *!
>
> Well, I have only been coding python for a few years, but I would say,
> along with writing unit tests, the great importance of not using
> import * is one of the secrets that you learn slowly and painfully
> with experience.  Chris' point about the movement of big projects away
> from that idiom is a very good one. It is convenient, but over time
> you realize that the value of convenience is far outweighed by the
> namespace mess and loss of clarity that results.
>
> Best,
>
> Matthew
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Re: [Matplotlib-users] [Numpy-discussion] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Matthew B. <mat...@gm...>]

Hi,

> import plab
>
> plab.plot() #etc.
>
> and interactive use could do from plab import *.

Yes...  It's a hard call of course.  I am a long term matlab user, and
switched to python relatively recently.  I do see the attraction of
persuading people that you can get something very similar to matlab
easily.  The downside about making numpy / python like matlab is that
you soon realize that you really have to think about your problems
differently, and write code in a different way.  I know that's
obvious, but the variables as pointers, mutable / immutable types,
zero based indexing, arrays vs matrices are all (fruitful) stumbling
blocks.  Then there is the very large change of thinking in an OO way,
pulling in other large packages for doing other tasks, writing
well-structured code with tests - all the features that python gives
you for an industrial strength code base.  And, the more pylab looks
like matlab, the more surprised and confused people will be when they
switch.  So,  I would argue that getting as close to matlab as
possible should not be the unqualified goal here - it is a real
change, with real pain, but great benefits.

Best,

Matthew

Re: [Matplotlib-users] [Numpy-discussion] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Barry W. <bar...@gm...>]

Matt,

Yes, I agree. I wasn't coming at so much from the goal of making Pylab
a Matlab clone (as you point out, that's silly, and misses much of the
advantage of Python), but rather from the goal of making interactive
use as efficient as possible. When I fire up ipython -pylab to do some
quick exploration, it's nice not to have to type N.blah or pylab.plot
etc. If I just import pylab *, however, then the commands I use may
not be what I expect from more formal coding where I use N.blah numpy,
S.foo for scipy, and pylab.bar for matplotlib. Making it easy for
users to have either namespace strategy, with consistent bindings, ala
the start of this thread is a good idea, IMO.

Well, I've said my piece. I'll get out of the way and let others have a crack...

Barry

On 2/18/07, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> > import plab
> >
> > plab.plot() #etc.
> >
> > and interactive use could do from plab import *.
>
> Yes...  It's a hard call of course.  I am a long term matlab user, and
> switched to python relatively recently.  I do see the attraction of
> persuading people that you can get something very similar to matlab
> easily.  The downside about making numpy / python like matlab is that
> you soon realize that you really have to think about your problems
> differently, and write code in a different way.  I know that's
> obvious, but the variables as pointers, mutable / immutable types,
> zero based indexing, arrays vs matrices are all (fruitful) stumbling
> blocks.  Then there is the very large change of thinking in an OO way,
> pulling in other large packages for doing other tasks, writing
> well-structured code with tests - all the features that python gives
> you for an industrial strength code base.  And, the more pylab looks
> like matlab, the more surprised and confused people will be when they
> switch.  So,  I would argue that getting as close to matlab as
> possible should not be the unqualified goal here - it is a real
> change, with real pain, but great benefits.
>
> Best,
>
> Matthew
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Re: [Matplotlib-users] [Numpy-discussion] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Neal B. <ndb...@gm...>]

I have never used matlab, but a lot of my colleagues do.  Can anyone give me
some good references that I could show them to explain the advantages of
python over matlab?

Re: [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats

[Chris B. <Chr...@no...>]

There's probably a better forum for this conversation, but...

Barry Wark wrote:
> Perhaps we should consider two use cases: interactive use ala Matlab
> and larger code bases.

A couple key points -- yes, interactive use is different than larger 
code bases, but I think it's a "Bad Idea" to promite totally different 
coding styles for these cases for a couple reasons:

-- One usually is doing both at once. I was a long-time, every day 
Matlab user, and hardly did anything of consequence interactively. I 
learned very quickly that it made a whole lot more sense to write a five 
line script that I could save, edit, etc. than do stuff interactively. 
Once I got something working, parts of that five line script might get 
cut&pasted into "real" code.

I do still test one or two lines interactively, but even then, I want 
the style to be something I can put in my code.

2) consistency in docs and examples is important, recommending different 
styles for interactive and programming use is just going to confuse 
people more.

3) even for folks that do a lot of interactive use, they are likely to 
write larger scale code at some point, and then they would need to learn 
something new.

> In the first case, being able to import * saves
> a lot of typing

No, it saves a little typing, if you're using an OOO style anyway.

 > and the namespace polution problem isn't a big deal.

Yes, it can be. A good interactive environment will be able to do things 
like method and command completion -- namespace pollution keeps that 
from working well.

> Returning to the OP's questions, why couldn't both cases be helped by
> creating a "meta-package" for numpy, scipy, and matplotlib? For the
> sake of argument, lets call the package "plab". Existing code could be
> affected by changing the individual packages, but a package that
> essentially does
> 
> from pylab import *
> from numpy import *
> from scipy import *


The issue with this is that you've now hidden where things are coming 
from. People seeing examples using that package will have no idea where 
things come from.

and by the way, the current "pylab", as delivered with MPL, pretty much 
does this already. I think we need to move away from that, rather than 
putting even more into pylab.

Matthew Brett wrote:
>  The downside about making numpy / python like matlab is that
> you soon realize that you really have to think about your problems
> differently, and write code in a different way.

Good point. A part of good Pythonic code is namespaces and OOO style. 
New users might as well learn the whole pile at once.

That all being said, it would be nice to establish a standard convention 
for how to import the key packages. I use:

import numpy as N
import matplotlib as MPL

But I don't really care that much, if we can come to any kind of 
community consensus, I'll follow it. The goal would be for all docs, 
Wiki entries, examples on the mailing lists, etc. to use the same style.

-Chris






-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Matplotlib-users] Unifying numpy, scipy, and matplotlib docstring formats

[<jk...@ik...>]

"Barry Wark" <bar...@gm...> writes:

> Yes, I agree. I wasn't coming at so much from the goal of making Pylab
> a Matlab clone (as you point out, that's silly, and misses much of the
> advantage of Python), but rather from the goal of making interactive
> use as efficient as possible. When I fire up ipython -pylab to do some
> quick exploration, it's nice not to have to type N.blah or pylab.plot

IMHO the greatest strength of Matlab in interactive use is the matrix
input format. For one thing, it is easier to type something like

  [0 1 0; 1 0 0; 0 0 1]

than

  array([[0,1,0],[1,0,0],[0,0,1]])

Granted, you can often leave out the array() wrapper, but typing all
the commas and brackets and getting the nesting right slows me down
enough that using Python feels like tedious work where Matlab is more
like an Emacs-like extension of the mind. Another neat feature is
auto-flattening: to e.g. add row- and column-wise sums and a grand
total to a matrix M, you can type

  [M sum(M,2); sum(M,1) sum(M(:))]

compared to which the r_[] and c_[] syntax feels like an ugly hack.

(Of course, the auto-flattening feature is a disaster for serious
programming (as opposed to quick interactive work), so Matlab has
added cell arrays which don't auto-flatten, leading to no end of
confusion between [] and {} indexing and the need to add {:} in
seemingly random spots in Matlab code.)

I suppose these things could be addressed quite neatly by IPython. 
It could even modify your history similarly to what it currently 
does with the %magic commands, so that when you type

  a = [0 1 0; 1 0 0; 0 0 1]

and then examine your history, you see

  a = array([[0,1,0],[1,0,0],[0,0,1]])

which you could copy-paste into the program you are developing.

Perhaps the namespace issue could also be addressed at the IPython
level. The pylab profile could import the various packages, perhaps
with some kind of abbreviated names, and rewrite commands like

  a = array(...)
  plot(sin(a))

to

  a = numpy.array(...)
  pylab.plot(numpy.sin(a))

so again you could copy/paste from the history to an editor and get
correctly Pythonic code without any "from ... import *". Probably a
100% solution is quite difficult because of the dynamic features in
Python, but it seems to me that a 80% solution should be feasible.
(Parse the input to an AST using the parser facility in the Python
library, use a tree walker to find all references to functions or
variables, and if they don't exist in locals() or globals() and are
not the target of an assignment anywhere in the AST, replace them by
references to the appropriate package.)

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Re: [Matplotlib-users] [Numpy-discussion] Unifying numpy, scipy, and matplotlib docstring formats

[Fernando P. <fpe...@gm...>]

Hi,

On 2/25/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:

> I suppose these things could be addressed quite neatly by IPython.
> It could even modify your history similarly to what it currently
> does with the %magic commands, so that when you type

Feel free to play with implementing this, it's easy to do so on your
personal setup, since input prefilter can be trivially added by any
user.  Once you find a set of tools that you're happy with, just send
them my way and we'll include them officially.

Here's some links you may find useful:

http://ipython.scipy.org/doc/manual/node7.html#SECTION00073000000000000000
http://ipython.scipy.org/doc/manual/node11.html

the code for these extensions ships already with ipython, under
IPython/Extensions.

Look at the one for quantities with units, it's a good starting point
for what you want to do.

> Perhaps the namespace issue could also be addressed at the IPython
> level. The pylab profile could import the various packages, perhaps
> with some kind of abbreviated names, and rewrite commands like

Ditto.

Regards,

f