[SciPy-user] Highlights from the Python10 conference.
eric at scipy.org
Mon Feb 11 10:33:10 CST 2002
We just got back from the Python conference, and I thought I'd give you an
update. Travis Oliphant and I gave a tutorial on Scientific Computing, and,
apart from my laptop not working with the projector, it went very well.
We'll try to get the slides up on the site as soon as possible. Travis' are
very good and will provide nice reference materials for many of the modules.
There was also a BoF on Scientific Computing and inling C/C++ in Python
where we discussed weave and PyInline. Both were well attended.
The Scientific Computing BoF was way to short and we didn't get to all the
The main issue discussed was whether we should change the default axis on
operations like sum, product, etc in both SciPy and the new NumArray module
so that all operations default to the same axis. There were multiple views
from "leave it like it is", to "force people to include it as an argument
(no default)", to "change it and provide a conversion script for people to
update old modules". I'll write up in another post to discuss the topic a
little further when I've gathered my thoughts on the issue a little more.
The second major topic was the discussion of having a NumArray/SciPy
workshop in the summer. The details haven't been worked out, but Patrick
Miller at LLNL has volunteered to help out with this. Its likely that it
will occur in the July timeframe in California at LLNL. We'll post more
details as they are available. Hopefully this will get off the ground.
This was mainly to let people know about weave and how it worked. Also, I
was interested in getting some hints on how to return values from C/C++ back
into Python. An off-line conversation with Barry Warsaw gave me some hints,
and comments by Skip Montanaro, Fred Drake, and Patrick Miller filled in a
few more details. It looks like I can do this by passing in the stack frame
object instead of the locals and globals dictionaries to the compiled
functions. I don't think it should be to hard.
The other exciting thing is that Patrick Miller has a cool package called
PyCod that actually translates Python byte code to C. It looks like it will
fold into weave quite nicely and has some potentially amazing capabilities.
Pat Miller (again...) got kinda excited about the idea of attempting to run
Matlab/Octave scripts using Python's VM -- or maybe a Matlab to Python
translator. If this can be made to work in a reliable way, it would be
Pat Miller (yes, we talked quite a bit :) and I discussed merging ideas from
pyMPI and cow.py for a more versatile set of parallel programming
capabilities. Pat and his LLNL colleague, Martin Casado, are real experts in
this area so there are some good possibilities here.
Paul Dubois really urged SciPy to work toward a peer reviewed process by
experts in each field to make sure the algorithms used are really the "best
of class" in there field. He also feels an strong object oriented interface
in SciPy to its underlying functions would be a huge win. He has some
papers in this area which I and others hope to read.
Janko Hauser offered to work on getting Numeric's documentation and some of
the SciPy modules in the same documentation format that Python uses.
We had long discussions on plotting with Perry Greenfield, Richard White,
Janko Hauser, Travis Oliphant, David Ascher and others (too many to list).
I'll summarize this in another posting also.
Michel Sanner from the Scripts Institute gave a talk about his AVS
work-alike package for visual programming. It is really cool and won the
best paper award! (congrats). You should definitely take a look at it:
David Beazley talked about SWIG's new features. Its come a long way baby
and now has a full C preprocessor, supports C++ templates, handles multiple
argument typemaps, and much more. This ain't your grandmother's C library
wrapper. More details at
There are also some possiblilities of parts of SWIG becoming Python modules
which has some interesting implications for weave.
I had a short talk with Dave about PLY also. It a Lex/Yacc type tool, and
it is apparently getting good reviews from users. You might want to check
it out his home page:
Todd Velantic, from SRI, gave a talk about how they retreive data from
*very* remote instrumentation (Radar, etc.) in Greenland, the South Pole,
etc. over very slow and periodically available connectivity. There solution
uses NNTP in a very clever way to send binary data around. It solved
multiple problems for them without reinventing the wheel.
Developers day had a session on optimizing the Python virtual machine by
Skip Montanaro and Jeremy Hylton. They have alternate approaches to
speeding up the thing. The long and the short of it is that there is a
little to squeeze out, but it looks like in the 5-30% range, not orders of
magnitude. Another approach adopted by the Psycho project actually does JIT
of Python byte codes to assembly language (at least this is as near as I can
tell what it does...) and can provide huge speed ups from 2-10 times by some
accounts. This has some promise, but also concern about how much effort
this avenue would require and whether it would truely result in a workable
solution. I don't know much about any of this stuff, but it was fun to
I missed the talk on the type/class merger ( had to catch a flight).
Fred Drake talked about a new profiler called HotShot that is in the Python
CVS now, but still needs some work. It sounds usable though, and is written
in C so that it is much faster and less invasive than the current profile
module which is written in C.
PyChecker by Neil ?? looks like a cool tool for checking for errors in
Python code. Guido was very excited about its capabilities, and thinks it
may get eventually folded into the compiler somehow (at least I think this
is what he said).
Attendance of the conference was slightly up from last year I believe. The
scientific community had a very strong presence there.
Lots more went on, but at least this hits a few highlights.
Eric Jones <eric at enthought.com>
Enthought, Inc. [www.enthought.com and www.scipy.org]
More information about the SciPy-user