Re: [Numpy-discussion] [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats
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 <matthew.brett@gmail.com> 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
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
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?
On Sun, Feb 18, 2007 at 01:10:53PM -0500, Neal Becker wrote:
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?
http://www.scipy.org/NumPyProConPage http://thread.gmane.org/gmane.comp.python.scientific.user/8950 http://groups.google.com/group/comp.lang.python/browse_frm/thread/a71af37fd9... -- Mike
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 <matthew.brett@gmail.com> 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
"Barry Wark" <barrywark@gmail.com> 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
Hi, On 2/25/07, Jouni K. Seppänen <jks@iki.fi> 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
On Sun, 25 Feb 2007, Jouni K. Seppänen apparently wrote:
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]])
x = numpy.mat('0 1 0; 1 0 0; 0 0 1').A hth, Alan Isaac
On Sun, Feb 25, 2007 at 06:44:37PM +0200, Jouni K. Seppänen wrote:
"Barry Wark" <barrywark@gmail.com> 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]])
A very nice shortcut in my opinion is the one supported by the HP scientific calculators (HP28, HP48 in my days), which would look like: array([[0,1,0], 1, 0, 0, 0, 0, 1]) I'm not quite sure how this could be generalized nicely for arbitrary shapes, but for arrays of rank 2 (which are a very common case where people are actually typing the values) it feels nice (especially on a french keyboard where the square brackets are awkward to type in) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D�veloppement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/
To get back to the original subject of the thread, there has been a commit today on the docutils plugins branch that allows folks to write their own parser/writer and somehow include it in docutils, without having to rebuild docutils. In other words, NumPy could define a plugin, and if docutils is installed, link the plugin to the docutils installation. This would allow third party package that use docutils to process numpy docstrings using the plugin. I don't know how far we can disgress from the reST syntax using those plugins, but it's probably something worth looking at. Check out: svn://svn.berlios.de/docutils/branches/plugins and the info about the plugin hookup is in docs/howto/extensions.txt David 2007/2/27, Alexandre Fayolle <alexandre.fayolle@logilab.fr>:
On Sun, Feb 25, 2007 at 06:44:37PM +0200, Jouni K. Seppänen wrote:
"Barry Wark" <barrywark@gmail.com> 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]])
A very nice shortcut in my opinion is the one supported by the HP scientific calculators (HP28, HP48 in my days), which would look like:
array([[0,1,0], 1, 0, 0, 0, 0, 1])
I'm not quite sure how this could be generalized nicely for arbitrary shapes, but for arrays of rank 2 (which are a very common case where people are actually typing the values) it feels nice (especially on a french keyboard where the square brackets are awkward to type in)
-- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBReP+816T+PKoJ87eAQITUQf/bVo3QH6hZV/kM71v89WzMODMeZb8IxXs BwoSSuL5YZGETKiR9wMmAcqVceJ6P0sW/5slWlJjXAONDfvcdTFkFaV1tyC2gWbP tTJu4kLe8BX7y/UsCM1y2U90GGI/LbYVAjMa+4HdWdsMoBTRN4tyeEuq/3Upg/rN GWW7+X+1poO1ZtjWDOpVS1DcZeioiYtsXvU0zAKe+briPM1QnIc1K2zfkwUBhA7F L7osi3uq+muucKE/sEpBQ9SotLbfJ+yFIZOYBSDiFPCSJi9bE6KvKVm+EfXt23KY 09dOd3rx+H471Pv90uzAVULLDUXucU/tKLBxVHhzMu6rzdb297QmfA== =1RL1 -----END PGP SIGNATURE-----
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
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 Chris.Barker@noaa.gov
participants (11)
-
Alan G Isaac -
Alan Isaac
-
Alexandre Fayolle -
Barry Wark -
Chris Barker -
David Huard -
Fernando Perez -
Jouni K. Seppänen -
Matthew Brett -
Michael Williams -
Neal Becker