[ANN] IPython 0.13 is officially out!
Hi all, on behalf of the IPython development team, and just in time for the imminent Debian freeze and SciPy 2012, I'm thrilled to announce, after an intense 6 months of work, the official release of IPython 0.13. This version contains several major new features, as well as a large amount of bug and regression fixes. The previous version (0.12) was released on December 19 2011, so in this development cycle we had: - ~6 months of work. - 373 pull requests merged. - 742 issues closed (non-pull requests). - contributions from 62 authors. - 1760 commits. - a diff of 114226 lines. This means that we closed a total of 1115 issues over 6 months, for a rate of almost 200 issues closed and 300 commits per month. We are very grateful to all of you who have contributed so enthusiastically to the project and have had the patience of pushing your contributions through our often lengthy review process. We've also welcomed several new members to the core IPython development group: Jörgen Stenarson (@jstenar - this really was an omission as Jörgen has been our Windows expert for a long time) and Matthias Bussonier (@Carreau), who has been very active on all fronts of the project. *Highlights* There is too much new work to write up here, so we refer you to our" What's New" document (http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html) for the full details. But the main highlights of this release are: * Brand new UI for the notebook, with major usability improvements (real menus, toolbar, and much more) * Manage all your parallel cluster configurations from the notebook with push-button simplicity (cluster start/stop with one button). * Cell magics: commands prefixed with %% apply to an entire cell. We ship with many cell magics by default, including timing, profiling, running cells under bash, Perl and Ruby as well as magics to interface seamlessly with Cython, R and Octave. * The IPython.parallel tools have received many fixes, optimizations, and a number of API improvements to make writing, profiling and debugging parallel codes with IPython much easier. * We have unified our interactive kernels (the basic ipython object you know and love) with the engines running in parallel, so that you can now use all IPython special tricks in parallel too. And you can connect a console or qtconsole to any parallel engine for direct, interactive execution, plotting and debugging in a cluster. *Downloads* Downloads can be found on: - Github: http://github.com/ipython/ipython/downloads - PyPI: http://pypi.python.org/pypi/ipython More download/install details: http://ipython.org/download.html. Please see our release notes for the full details on everything about this release: http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html As usual, if you find any other problem, please file a ticket --or even better, a pull request fixing it-- on our github issues site (https://github.com/ipython/ipython/issues). Many thanks to all who contributed! Fernando, on behalf of the IPython development team. http://ipython.org -- http://mail.python.org/mailman/listinfo/python-list
A sad day for the scientific Python community. John Hunter, creator of matplotlib: 1968-2012.
Dear friends and colleagues, I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those on the mailing lists, solve difficult technical problems in matplotlib, teach courses
[ANN] IPython 0.11 is officially out
Hi all, on behalf of the IPython development team, I'm thrilled to announce, after more than two years of development work, the official release of IPython 0.11. This release brings a long list of improvements and new features (along with hopefully few new bugs). We have completely refactored IPython, making it a much more friendly project to participate in by having better separated and organized internals. We hope you will not only use the new tools and libraries, but also join us with new ideas and development. After this very long development effort, we hope to make a few stabilization releases at a quicker pace, where we iron out the kinks in the new APIs and complete some remaining internal cleanup work. We will then make a (long awaited) IPython 1.0 release with these stable APIs. *Downloads* Download links and instructions are at: http://ipython.org/download.html And IPython is also on PyPI: http://pypi.python.org/pypi/ipython Those contain a built version of the HTML docs; if you want pure source downloads with no docs, those are available on github: Tarball: https://github.com/ipython/ipython/tarball/rel-0.11 Zipball: https://github.com/ipython/ipython/zipball/rel-0.11 * Features * Here is a quick listing of the major new features: - Standalone Qt console - High-level parallel computing with ZeroMQ - New model for GUI/plotting support in the terminal - A two-process architecture - Fully refactored internal project structure - Vim integration - Integration into Microsoft Visual Studio - Improved unicode support - Python 3 support - New profile model - SQLite storage for history - New configuration system - Pasting of code with prompts And many more... We closed over 500 tickets, merged over 200 pull requests, and more than 60 people contributed over 2200 commits for the final release. Please see our release notes for the full details on everything about this release: https://github.com/ipython/ipython/zipball/rel-0.11 * Resources * You can see a talk about this release that was presented at the Scipy 2011 conference: http://www.archive.org/details/Wednesday-203-6- IpythonANewArchitectureForInteractiveAndParallel For reference, the slides that go along with it are here: http://fperez.org/talks/1107_ipython_scipy.pdf And there's an excellent blog post, written by Chris Fonnesbeck, providing a visual tour of our new features: http://stronginference.com/weblog/2011/7/15/innovations-in-ipython.html As usual, if you find any problem, please file a ticket --or even better, a pull request fixing it-- on our github issues site (https://github.com/ipython/ipython/issues/). Many thanks to all who contributed! Fernando, on behalf of the IPython development team. http://ipython.org -- http://mail.python.org/mailman/listinfo/python-list
Re: array subset could be improved? -repost ;)
Jim O'D wrote: > Hi all > > I have an array a=array([2,3,-1]). > > I want to extract an array with all the elements of a that are less than 0. Numeric is currently changing into the new scipy core. If you are willing to play with beta code, get it here: http://numeric.scipy.org if not, wait a little for an official release. With the new numeric, you'll be able to do: negatives = a[a<0] Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Yes, this is a python question, and a serious one at that (moving to Win XP)
> Kenneth McDonald a écrit : >> For unfortunate reasons, I'm considering switching back to Win XP (from >> OS X) as my "main" system. Windows has so many annoyances that I can >> only compare it to driving in the Bay Area at rush hour (OS X is like >> driving in Portland at rush hour--not as bad, but getting there), but >> there are really only a couple of things that are really, absolutely >> preventing me from making the switch. Number one is the lack of a >> decent command line and command-line environment, and I'm wondering >> (hoping) if perhaps someone has written a "Python shell"-- something >> that will look like a regular shell, let users type in commands, maybe >> have some of the nice features of bash etc. like tab completion, etc, >> and will then execute an underlying python script when the command is >> entered. I'm not thinking of IDLE, but something that is really aimed >> more at being a system terminal, not a Python- specific terminal. >> >> Yes, I know that Cygwin is out there, but last I looked, they still >> went through the Win command-line window, which imposes a lot of >> restrictions. You can look at ipython: http://ipython.scipy.org. Its 'pysh' profile does much of what you describe, and has a dedicated following of win32 users precisely for your usage case. It gets installed to your start menu under win32 as a separate entry from the 'raw' ipython. Stop by the users list if you have further questions. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: need an example of Python numarray to C++ and back again, Boost / SWIG?
PL wrote: > I want to pass a 2D array from Python to C++, manipulate it in C++ (for > example, add 1 to each element) and pass it back to Python. > > With these building blocks I will be able to figure out all the rest of > what I need to do for my project. I am very familiar with Python, but > less so with C++ and Boost or SWIG. > > Does anyone have an example with all steps that I can follow? More > specifically I am looking for the C++ code, ".i" file for SWIG and/or > the analagous setup files that Boost would need to do this. You may want to look into weave.inline or weave.blitz, from scipy. Typemaps for conversion to blitz++ were recently posted on the scipy list: http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2883831 In particular look at Stefan's post. For info on weave, here you can find some old slides and example code: http://amath.colorado.edu/faculty/fperez/python/ Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Command-line tool able to take multiple commands at one time?
Peter A.Schott wrote: > Per subject - I realize I can copy/paste a line at a time into an interactive > session when I'm trying to debug, but was wondering if there is any tool out > there that allows me to copy sections of working Python scripts to paste into > my interactive console and let those run so I don't have to copy line-by-line. > > Not sure if iPython would meet that criteria or not or even if such a beast > exists. It would be helpful for debugging some of my simpler, yet still > lengthy at times, scripts. ipython has a %run command designed precisely to do this. You can keep your favorite editor open and work on your code. You just need to save and type into ipython 'run scriptname', to re-execute the code each time just as if you'd typed it. Note that ipython uses readline, so you just need to type 'r' and hit the up-arrow key to retrieve the previous command starting with the letter r. Type 'run?' (without the quotes) into ipython to get the gory details on the run command, or have a look at the manual here (scroll down to the %run part): http://ipython.scipy.org/doc/manual/node6.html#SECTION00062100 Feel free to ask further questions on the ipython list, I don't keep up with c.l.py too well these days, unfortunately. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: exceptions, internals (introspection?)
ej wrote: > I have often wondered how to get at other internals, such as the name of > the current function, file, line number I am in? The arguments to the > current function, etc. I browsed through the table of contents of both the > Library Reference & Language Reference. I see section 18. Python Language > Services. In browsing through that, I'm thinking "Oh man... this is way > more than I need - there's got to be an easier way." Nothing else is > jumping out at me. Can someone point me to some documentation on this > subject and/or provide some examples? Poke around IPython, which implements a pretty massive amount of functionality in this direction. In particular, you want to read OInspect.py and ultraTB.py. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: need an example of Python numarray to C++ and back again, Boost / SWIG?
PL wrote:
> I looked at Stefan's post - but he remarks that "Unfortunately, Blitz
> jealously guards its data (restricted pointers), so that it is not so
> easy to do the conversion in the other direction. If anyone knows an
> answer to this problem, I'd be glad to hear it"
>
> I've previously looked at Phillip Austin's 'num_util' and Paulo J. S.
> Silva's 'COIN' example, but even from those two, I can't figure out a
> way to do: Python 2D numarray --> C++ (process array) --> Python 2D
> numarray.
I may be missing something, but what I've done in the past for this is have the
C++ code simply reuse the Numeric data pointer. This way, when I exit the C++
extension (I've used blitz++ for the job), the array as seen from the python
side has been 'magically' modified. Obviously this means that I can't allocate
new arrays in C++ which can be transfered over to python without paying the
price of a copy, but in my cases that hasn't been a problem: I do all
'allocations' in python (via arr=Numeric.empty(...)) and let the blitz code
fill in the arrays.
This has the advantage that the blitz array creation is extremely cheap, as only
the shape tuple needs to be copied (not the data region). The following little
snippet is pretty much all that's needed if the above description happens to
work for you. This code is mostly taken from weave's internals:
// -*- C++ -*-
#ifndef PY_TO_BLITZ_H
#define PY_TO_BLITZ_H
#include "Python.h"
#include "Numeric/arrayobject.h"
#include "blitz/array.h"
using namespace blitz;
// Convert a Numpy array to a blitz one, using the original's data (no copy)
template
static Array py_to_blitz(const PyArrayObject* arr_obj)
{
const int T_size = sizeof(T);
TinyVector shape(0);
TinyVector strides(0);
int *arr_dimensions = arr_obj->dimensions;
int *arr_strides = arr_obj->strides;
for (int i=0;i((T*) arr_obj->data,shape,strides,neverDeleteData);
}
#endif // PY_TO_BLITZ_H
Cheers,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: Readline configuration
Mark Roach wrote: > I have readline set up pretty much the same way as in the example in the > python docs (http://docs.python.org/lib/readline-example.html) and > something I find myself doing fairly often is > > type some code > more code > more code > ... > > and then wanting to scroll back through the history to run the same code > again after a module = reload(module). In Windows, this is pretty > convenient as I can use up to move to point x in the history, press enter, > and press down to move to point x+1 in history. Is there any way to get > the same behavior with readline? > > It would be great to be able to ctrl+r then just > hit down+enter to reenter the rest of the code. See ipython (http://ipython.scipy.org). It provides mostly what you want: In [1]: for i in range(3): ...: print i, ...: 0 1 2 In [2]: print 'hello' hello In [3]: exec In[1] 0 1 2 Readline history search is bound to Ctrl-P/N (type a few characters, then hit Ctrl-P/N to get previous/next lines with those matching chars). Ctrl-r search is also configured by default. HTH, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Display Function Code Body?
Haibao Tang wrote: > > Hail Python pals! I played with the R (http://r-project.cran.org) last > night to do some statistics and it has an interactive session too, and > I found a feature that is quite useful. [...] > # or any shallow function code from a file import calendar; disp(calendar.isleap) > > def isleap(year): > """Return 1 for leap years, 0 for non-leap years.""" > return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0) > > > # surely the compiled function code cannot be displayed disp(blabla) > > : internal/compiled function > > > Can someone please point out how this can be achieved nicely. I've > tried some text searching approach, too dirty I must say. > Oh! Thank you ... [~/tmp]> ipython Python 2.3.4 (#1, Oct 26 2004, 16:42:40) Type "copyright", "credits" or "license" for more information. IPython 0.6.7_rc1 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help-> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: import calendar In [2]: calendar.isleap?? Type: function Base Class: String Form: Namespace: Interactive File: /usr/src/build/475206-i386/install/usr/lib/python2.3/calendar.py Definition: calendar.isleap(year) Source: def isleap(year): """Return 1 for leap years, 0 for non-leap years.""" return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0) Note that the source display won't work for interactively defined functions, because their source is thrown away by the bytecode compiler. There are discussions of a PEP for adding a __source__ attribute to functions which would solve this limitation, but that is still in the future. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Installer made with bdist_wininst segfaulting...
Hi all,
I am seeking advice/help from those with more win32 experience than myself. I
am trying to build a proper win32 installer for IPython, after a user did most
of the hard work. For the most part, it's working very well, but I am running
into a nasty problem, which took me a few hours to finally understand. This
smells to me like a python bug, but I could be wrong. Much googling didn't
turn up anything relevant.
Here is a brief summary: if the installer file is run from a windows drive which
is different from the one where python resides (and hence where ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).
The win32 laptop where I'm testing, for example, has user stuff in the D: drive,
and Python installed in C:\Python23. I was running the installer from D:\Temp,
and getting this segfault. If I run it from C:\Temp, it works perfectly.
I have put the installer here, in case someone else is willing to test this on a
different machine:
http://amath.colorado.edu/faculty/fperez/tmp/ipython-0.6.9.win32.exe
I have narrowed down to a single os.chdir() call in the post-install script.
The code is simply:
# Lookup path to common startmenu ...
d = get_special_folder_path('CSIDL_COMMON_PROGRAMS') + r'\IPython'
# Create IPython entry ...
if not os.path.isdir(d):
os.mkdir(d)
directory_created(d)
# XXX - The binary installer segfaults here if it was being run from a
# different drive than it is trying to change to. In my case, I have
# everything in D:, but Python lives in C:, so the chdir() call is going
# from D: to C:, and this is crashing things.
print "Current dir:",os.getcwd() # dbg
print "Going to :",d # dbg
os.chdir(d)
By forcing a return before the chdir() call, I was able to see that when the
source/destination are both on C:, it's all OK, but when the source is in D:
and the destination in C:, I get the crash.
This is really frustrating, since I'd like to be able to stop distributing .zip
sources to Windows users, and would like to be able to provide a proper
installer/deinstaller. But having this thing crash if two drives are involved
is just not acceptable.
Any help from the win32 gurus out there would be much appreciated. For
reference, the binary installer linked above was created on a Fedora3 box
running pyhton 2.3.4, with the command line:
./setup.py bdist_wininst --install-script=ipython_win_post_install.py
Cheers,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: Installer made with bdist_wininst segfaulting...
Hi Thomas, Thomas Heller wrote: > Fernando Perez <[EMAIL PROTECTED]> writes: >> Here is a brief summary: if the installer file is run from a windows drive >> which is different from the one where python resides (and hence where >> ipython will >> end up), the installer segfaults. No traceback, nothing, just a segfault >> (well, one of those Windows dialogs asking me to send a binary traceback to >> Redmond, but not a proper Python traceback). > > There are a couple of known bugs in bdist_wininst, and you just reported > another one. All these bugs are related to using the > post_install_script, and show up when either (thats what I currently > remember): [...] many thanks for following up on this. In my case, I realized I could avoid the chdir() call and things were then OK. But it's good to see the bug fixed. Best regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Installer made with bdist_wininst segfaulting...
Thomas Heller wrote: > There are a couple of known bugs in bdist_wininst, and you just reported > another one. All these bugs are related to using the > post_install_script, and show up when either (thats what I currently > remember): > > - the installer is run from a readonly location, > - the installer is run from a different drive (as you reported) > - the installer installs for Python 2.4 > > I will fix these issues in Python 2.3.5, which will probably be out as a > release candidate this week, and in Python 2.4.1. One more small thing I just remembered... In my testing, I noticed the installer, even when it succeeds, leaves little temp files littering the root directory of the drive it was run from. These seem to be the files where stdout is captured, but they should be explicitly removed at the end. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: gnuplot on Canvas widget
Jonathan Ellis wrote: > Blues wrote: >> I have used two great models - Tkinter and Gnuplot.py - for a while. > I >> can display an image on a Canvas widget using Tkinter and I can also >> generate a gnuplot from Python on the fly in a separate window. Does >> anyone know how to display such a gnuplot on the Canvas widget with > an >> image in it? Thanks. > >>From my experience, the Gnuplot module isn't designed to be used in > "headless" mode -- it can save to the usual formats, but you have to > render everything in an x11 window interactively first. > It might not be hard to modify this, though. That's not correct. I have tons of Gnuplot.py based scripts which write directly to EPS output, without ever opening a gui window. Note that Gnuplot still tries to initialize the X11 terminal at startup, so they would require modifications to run over ssh without X forwarding. The default plot() command in Gnuplot.py doesn't make it too convenient to do this, but it's possible. The Gnuplot support in ipython (http://ipython.scipy.org) extends the syntax of the plot() command to make it trivial to render to EPS without a terminal. It shouldn't be hard to modify this to render to other formats, while avoiding opening an X11 window. Best, f -- http://mail.python.org/mailman/listinfo/python-list
ANN: IPython 0.6.10 is out.
Hi all, I'm glad to announce the release of IPython 0.6.10. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (for Python 2.3, built under Fedora Core 3), plus source downloads (.tar.gz). We now also have a native win32 installer. Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. What is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. Release notes - As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. * The major highlight of this release is vastly improved support for Windows users. Thanks to a lot of help from Viktor Ransmayr (installer work) and Gary Bishop (coloring problems), now Windows users finally should have an ipython with all the functionality available under Unix. There is now a true win32 executable installer: http://ipython.scipy.org/dist/ipython-0.6.10.win32.exe This can be double-clicked and it will do a real windows installation, allowing later de-installation via the Control Panel. It will also warn if it detects that ctypes and/or readline are missing (needed for coloring/tab support). Full source syntax highlighting had always been broken under win32, and the bug turned out to be in ipython's formatting code. Thanks to Gary's debugging help, this problem is now fixed. You can test it by typing in ipython: import code code?? You should see properly highligted sources, as shown in this (new) screenshot: http://ipython.scipy.org/screenshots/snapshot6.png Under Win32, ipython will now honor (if it exists) the $HOME environment variable and it will put your .ipython/ directory there. This should be more consistent for Win32 users who have a unix-like setup. If $HOME is not defined, the previous behavior remains (HOMEDRIVE\HOMEPATH). I also fixed a crash for pylab users under win32 with multithreaded backends (GTK/WX). I would appreciate reports of any problems from Win32 users. * (X)Emacs users: I incorporated Alex Schmolck's recent fixes and improvements to ipython.el. Since the python-mode project still hasn't made a release with the changes which IPython needs, I've temporarily copied today's CVS snapshot (v 4.70) of python-mode.el here: http://ipython.scipy.org/tmp/python-mode.el Once they make an official release, I'll remove this. * Small cleanups and improvements to numutils, including new amin/amax and empty_like utility functions. The deprecated spike/spike_odd functions have been removed. * Fix issue 24 from the bug tracker: spurious attribute access on assignment (foo.x=1 would trigger a __getattr__ call on foo). * Fix reporting of compound names in verbose exception reporting mode. This had been broken since the beginning of ipython (the tokenization logic was a bit tricky). * Fix gtk deprecation warnings (A. Straw patch). * Fix crash when inspecting instances without an __init__ method (reported by N. Nemenc). * Fix quote stripping bug in shell access (P. Ramachandran report). * Other minor fixes and cleanups, both to code and documentation. Enjoy, and as usual please report any problems. Regards, Fernando. -- http://mail.python.org/mailman/listinfo/python-list
bdist_wininst post-install bug?
Hi all, I just noticed a problem (which forced me to a last-minute update of the windows ipython installer). As far as I can tell, this should be considered a bug. >From the Python docs, sys.executable is: executable A string giving the name of the executable binary for the Python interpreter, on systems where this makes sense. However, during the execution of a post-install script, this string actually resolves to the name of the binary installer! This name should resolve, I think to the name of the Python executable for which the installer is running (a value selectable at the start of the installation, if more than one Python is detected). Having this value available allows you to properly generate shortcuts with the proper full path to the python executable. I resorted to using sys.prefix+r'\python.exe', which will most likely work, but I'd rather see sys.executable give me a more sensible answer. Should this be filed as a distutils bug? I'd rather not clog the database if it was the result of a deliberate decision, as strange as it may seem to me. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Numeric with ATLAS and LAPACK
drife wrote: > Thanks John. Those are the steps I followed, and to no avail. > > Interestingly, I downloaded and installed SciPy, and ran the > same eigenvector problem. SciPy greatly speeds up the > calculation...was 1.5 hours using Numeric, now only 15 min > with SciPy. > > Unfortunately, SciPy only solves ordinary and generalized > eigenvalue problems of a square matrix. They do not test > to see if the matrix is symmetric, then call the appropriate > routine from LAPACK. Note that scipy exposes most of lapack, so you could make the call you need directly: In [3]: scipy.linalg.lapack.get_lapack_funcs? Type: function Base Class: String Form: Namespace: Interactive File: /usr/lib/python2.3/site-packages/scipy/linalg/lapack.py Definition: scipy.linalg.lapack.get_lapack_funcs(names, arrays=(), debug=0, force_clapack=1) Docstring: Return available LAPACK function objects with names. arrays are used to determine the optimal prefix of LAPACK routines. If force_clapack is True then available Atlas routine is returned for column major storaged arrays with rowmajor argument set to False. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Numeric with ATLAS and LAPACK
drife wrote: > Could you clarify this please? > > Let's say that I want to make a call to the LAPACK > routine sspevd, and pass it a matrix, and get the result. How do I > accomplish this? I just had a quick look, and it seems that sspevd is NOT one of the already wrapped LAPACK functions. Try dir(scipy.linalg.flapack) and dir(scipy.linalg.clapack) to see what's been already wrapped. From what I understand, wrapping more of lapack is rather easy, it's just that nobody has committed the time to 100% coverage. But this question is much better posed on the scipy list, where the people who wrote the lapack wrapping code can give you a better answer (I didn't). Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Image stats - going from Matlab to Python
[EMAIL PROTECTED] wrote: > Hi all, > I am working with images in python using PIL. I come from a MATLAB > background so I am finding it to be sometimes frustrating to do things > correctly and quickly. All I need to do is load an image and store a > list of pixel coordinates at which the alpha channel is set to 1. > In Matlab this would be easy...Lets say we have a 2x2x4 array that > represents the image. I would just type something like: > > indices = find(im(:,:,3)==1); > > then work with indices to get xy coords. Is there a similar way to > accomplish the same thing in python and PIL without having a nested for > loop and checking every pixel? > I would appreciate advice. Thanks very much for your attention! The kind of array functionality which you have in mind is implemented in python by the Numeric/Numarray libraries. You can (and should) use the PIL for the more image-specific tasks, but basic array things are done via those others. You may also want to look at matplotlib, for a high level, matlab-compatible plotting library. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: python-mode tab completion problem
Skip Montanaro wrote: > > test1dellboy3> I am exploring python-mode on emacs. When I open foo.py > test1dellboy3> in emacs and hit C-!, it starts the python interpreter in > test1dellboy3> another window. Next, I execute - > > ... > > That's not really intended to be used as an interactive session with all > sorts of bells and whistles. Or he can use ipython, which with the special ipython.el companion file and a recent (CVS) python-mode, will give him true tab completion (with options listed in an emacs *completions* buffer) for all objects. With ipython's %pdb active, it will also open up the source at any uncaught exception, at the line of the exception. Very handy for debugging. Regards, f ps. All this fanciness is thanks to the sustained efforts of A. Schmolck and P. Ramachandran, I'm just happy to use them (I can't code a line of elisp). -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Ashot wrote: > I am using IPython in windows and the LightBG setting doesn't correctly > because the background of the text is black even if the console background > is white. Anyone know whats going on? Thanks. It's quite possible that it's a bug in the UNC readline implementation proper. How do you set the background to white? Is this something that can be done for the normal winxp terminal, or do you use a different terminal emulator? I'd like to have more detailed info before I contact the readline author. He's done a great job of providing ANSI-compliant color escape handling for the piece of junk which MS ships as a terminal, but it's quite possible that he may have missed something for the case of light backgrounds. Regards, f (ipython author) -- http://mail.python.org/mailman/listinfo/python-list
Re: exporting mesh from image data
John Hunter wrote: > > I am trying to generate a mesh for a finite volume solver (gambit, > fluent) from 3D image data (CT, MRI). To generate the fluent msh > file, you need not only a list of vertices and polygons, much like > what is available in the vtk file format, but also the volume elements > in the mesh that the polygons abut. Eg for a given triangle in the > mesh, you would have a line like [...] I hope you posted this on the VTK list with a CC to Prabhu as well... The hopes of a positive reply there are, I suspect, a fair bit higher. The scipy list would be a good idea, too. I don't have an answer, but I recall seeing something about a finite volume solver implemented in python recently. Interestingly, a quick googling on those terms turned this up: http://math.nist.gov/mcsd/Seminars/2005/2005-03-01-wheeler.html Note the March 1 Boulder meeting :) (the coordinated times suggest a videoconference of sorts). I'll most likely attend the talk, let me know if you still don't have a solution by then and I can try to talk to Wheeler (if he's physically here instead of in Gaithesburg). For all we know, their code might provide an implementation, have a look (I'd be quite interested in your opinion if you've already looked at it). Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: exporting mesh from image data
John Hunter wrote: >>>>>> "Fernando" == Fernando Perez <[EMAIL PROTECTED]> writes: > > Fernando> I hope you posted this on the VTK list with a CC to > Fernando> Prabhu as well... The hopes of a positive reply there > Fernando> are, I suspect, a fair bit higher. The scipy list would > Fernando> be a good idea, too. > > Hey Fernando, > > I did get some help from Prabu off list. The suggestion was to use a > vtkDelaunay3D to mesh the isosurface points into a volume, which > returns an unstructured grid, and then iterate over this structure to > get the volume, face, vertex and connectivity information out. I've > implemented this and we're in the process of testing it with some > simple geometries. If/when I get something tested and working, I'll > post it. > > Thanks for the links, > JDH I should have thought of that, obviously. Watch out for edge problems with Delaunay triangulations: http://amath.colorado.edu/faculty/fperez/faults/ Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Claudio Grondi wrote: > I use this one, > http://heanet.dl.sourceforge.net/sourceforge/uncpythontools/readline-1.7.win > 32.exe > which I assume is the right one. Try version 1.8, some coloring problems have been recently fixed. If that doesn't do it, let me know and I'll try to get in touch with the author to see if he can help. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Ashot wrote: > this is what it looks like: > > http://www.freshraisins.com/sand/ipythonscreen.PNG > > does cygwin have a readline utility in it? Perhaps this is overriding the > correct one? Thats the only thing I can think of. Thanks for the screenshot. I've contacted the readline author, I'll report back when there are news about a possible fix. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Ashot wrote: > this is what it looks like: > > http://www.freshraisins.com/sand/ipythonscreen.PNG > > does cygwin have a readline utility in it? Perhaps this is overriding the > correct one? Thats the only thing I can think of. Hi folks, could you please test under windows the 1.9 version of readline? http://sourceforge.net/project/showfiles.php?group_id=82407&package_id=84552&release_id=302513 This was just put up a moment ago by the developer, let me know if it fixes these problems. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Fernando Perez wrote: > Hi folks, > > could you please test under windows the 1.9 version of readline? > > http://sourceforge.net/project/showfiles.php?group_id=82407&package_id=84552&release_id=302513 > > This was just put up a moment ago by the developer, let me know if it fixes > these problems. Never mind. He contacted me briefly after I wrote this, with the following info: I just checked. The new version does not fix that problem. The code as released does not handle backgrounds other than black. Folks should run with a black background for now. So for now, I'm sorry to say this but under win32, ipython users should stick to dark backgrounds. I'll post a note here when the readline developer has a chance to work on this problem. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Fernando Perez wrote: > Ashot wrote: > >> this is what it looks like: >> >> http://www.freshraisins.com/sand/ipythonscreen.PNG >> >> does cygwin have a readline utility in it? Perhaps this is overriding the >> correct one? Thats the only thing I can think of. > > Hi folks, > > could you please test under windows the 1.9 version of readline? OK, make that 1.10: http://sourceforge.net/project/shownotes.php?release_id=302526 Gary specifically targeted the light background problems with this one, so please report here if the whole thing gets fixed. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Ashot wrote: > One more thing I was wondering about: why not highlight the source code in > the errors since you already have this functionality (with '??' command). > It would be nice to have it highlighed on the prompt as well, but I > imagine this may be more difficult.. I've been using IPython for about a > week and thats one of the two things I miss.. On the input line, there's no way: ipython only gets what you type when you hit return. It would require writing a full-blown IDE to get that. For the errors, it's a bit tricky because I'd have to use the tokenization code right inside the exception traceback builder. That's not particularly easy, esp. considering that the traceback handler doesn't necessarily have full code objects. Tokenizing a chunk of code which may begin half-way through a function, with possibly an open triply-quoted multiline string in the middle, can get tricky. I'm not saying it's impossible, but it's certainly not a very straightforward task. I simply haven't found it to be a priority, given that other parts of ipython need a lot more work. Heck, those tracebacks are already miles ahead of what you get from plain python (try 'xmode verbose' for real detailed info), so for now I'm willing to leave them as they are. But since it's definitely something which would be a nice improvement, I'll gladly accept any patches which implement it in a clean, robust way. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Ashot wrote: > whoa, that was quick, looks like it works for me. Thanks a lot! > It would be nice to be able to set the colors in the prefs file, although > its possible to edit the pyColorize file as Claudio mentioned. Yes, I haven't implemented user-definable color schemes. Not impossible, but not a priority at the moment (much bigger fish to fry). Sorry 'bout that (patches welcome, though). Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IDLE history, Python IDE, and Interactive Python with Vim
Hi, Ashot wrote: > This is sort of both Python and Vim related (which is why I've posted to > both newsgroups). [...] I know you've been using ipython recently (the readline color bugs), so perhaps my reply is a bit redundant. Forgive me if that's the case, I just want to give you some useful info. Just in case you haven't come across these features (the manual is kind of long and dry), I should note that ipython has pretty much everything you've asked for here. %hist -n dumps your history without line numbers (for copy/paste), %logstart gives you an incremental log (valid python code) of your current session, %save allows you to save a selected group of lines to a file, and %edit will open up $EDITOR (or vi in Unix by default) at the source of any accessible object. With %pdb, you can even trigger automatically pdb at any uncaught exception (in Emacs, you'll even get the source simultaneously opened, I'm sure something similar could be done for vi). Ipython is not an IDE, but it does offer an extensible command-line environment which tries hard to be very efficient. Hopefully this year I'll be able to work on integrating it (optionally, since it will never lose its command-line functionality) with GUIs as well. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: question about introspection using inspect module
Benjamin Rutt wrote: > I'm trying to learn about introspection in Python. my ultimate goal > is to be able to build a module "text database" of all modules that > are in the sys.path, by discovering all candidate modules (I've > already done that), importing all of them, and then introspecting on > each module to discover its functions, globals and classes. But for > now I am having a problem with the latter. I certainly don't want to discourage you from learning about python introspection, it's one of the most fun aspects of the language. But just as an FYI, the pydoc system already does much of what you have in mind, at least if I'm reading your description correctly: planck[/tmp]> pydoc -p 12345 pydoc server ready at http://localhost:12345/ Just point your favorite webbrowser to that URL (use any port number you want, and which isn't already in use). Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: question about introspection using inspect module
Benjamin Rutt wrote: > Fernando Perez <[EMAIL PROTECTED]> writes: > >> I certainly don't want to discourage you from learning about python >> introspection, it's one of the most fun aspects of the language. But just >> as an FYI, the pydoc system already does much of what you have in mind, at >> least if I'm reading your description correctly: >> >> planck[/tmp]> pydoc -p 12345 >> pydoc server ready at http://localhost:12345/ > > thanks, I'm aware of that actually, and seeing all the information > available there was inspiring to me. OK, you never know :) > what I am actually trying to do is to build a database of Python > modules. so then later, I can write a tool in my favorite editor > (Emacs) to invoke some forms of completion against this database > (e.g. os.remov or socket. to see a list of all socket module > definitions). well, I have no idea if this will be of any use, but it might: http://cedet.sourceforge.net/ I use their speedbar quite a bit, but it sounds from the description like they have some other fancier tools. I'd be quite curious to know if they play nicely with python (they mention C++ explicitly), and how much value they add. Let me know if you are familiar with them, or if you end up investigating these further. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: PyX, matplotlib, 3D & LaTeX
Francisco Borges wrote: > I like PyX, use it a lot and would suggest it as a beter plotting > library than the ones at Scipy (for as long as you don't need on-screen > plotting). FWIW, the plotting support in scipy is essentially unmaintained and abandoned, since the advent of matplotlib. It hasn't been officially deprecated, though I'm wondering if perhaps we should do that just to save users the aggravation. > I just saw matplotlib this week while searching for something that > would do 3D, it seemed pretty nice and it does have many more features > than PyX, is certainly more mature than PyX and more high level. I use both extensively, so I can comment a bit: matplotlib is a fantastic _plotting_ library, and it has very extensive support for doing all kinds of plotting-related things easily and with high output quality. As of v. 0.82, its latex support is on-par with Pyx's, since now you can set it to do _all_ your text rendering (including ticks, numbers, etc.) via latex. It gets a bit slower (much like pyx), but the quality is perfect (it's true latex running underneath). Besides, matplotlib provides widgets for on-screen rendering and embedding into GUI applications, something which can be very important, and outside pyx's domain of interest. Where pyx shines is for generating what I call 'diagrams' for lack of a better term: drawings that don't fall well into the model of 'plot these data points at these coordinates' but that rather involve algorithmically-driven positioning of geometric elements. This power is best seen (despite my poor description) by just looking at the pyx examples page, which shows how even relatively complex diagrams can be done in pyx with very little code, and give stunning results. While you can plot with pyx, and draw with matplotlib, I feel that they each have their strengths, and I use both. I love both, and I feel they complement each other extremely well. For 3d plotting in python, VTK and mayavi are my workhorses, and I'm quite happy with that solution so far. > On the other hand PyX: LaTeX support seems to be way ahead and it can > be used to draw (very funky) figures. [have a look at recent matplotlib for proper latex] Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: goto
Steven Bethard wrote: > Hayri ERDENER wrote: >> what is the equivalent of C languages' goto statement in python? > > Download the goto module: > http://www.entrian.com/goto/ > And you can use goto to your heart's content. And to the horror of all > your friends/coworkers. ;) > > STeVe That is actually a _really_ cool piece of code, in terms of showing off the kind of things which are possible in python if you're willing to be a little sneaky. Thanks for the pointer ! best f -- http://mail.python.org/mailman/listinfo/python-list
Re: goto
Steven Bethard wrote: > Fernando Perez wrote: >> Steven Bethard wrote: >> >>>Download the goto module: >>> http://www.entrian.com/goto/ >>>And you can use goto to your heart's content. And to the horror of all >>>your friends/coworkers. ;) >> >> That is actually a _really_ cool piece of code, in terms of showing off the >> kind of things which are possible in python if you're willing to be a little >> sneaky. > > Yeah, it's pretty slick. I think most people who see the link don't > realize that it's actually *working code* for gotos in Python. For a second I didn't think it was, but the page looked too serious to be just a mockup (regardless of the April's fool warning at the top). So I actually donwloaded the code to see how he did it, because it wasn't quite obvious to me after the standard 3 seconds of thought. It was quite fun the read how he got it to work. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Peter Hansen wrote: > Michael Hoffman wrote: >> For the PEP, do any of you have arguments for or against including path? >> Code samples that are much easier or more difficult with this class >> would also be most helpful. > > I believe the strongest argument for "path" can be made for how it > integrates functionality which, although closely related conceptually, > is currently distributed across a half dozen or more different modules > in the standard library. Especially for newbies (I can only imagine, at > this stage) it would make working with files much easier in a many ways. +10 One of the few things that annoys me about the stdlib is what one could call performing 'shell-scripting-like' tasks, and precisely because of the problem you point out. A number of conceptually related and common tasks are scattered all over, and every time I need to write this kind of code, I find myself paging over the docs for multiple modules, with no real intuition as to where I could even guess where to find things. This is very unusual for python, where in most cases things are so well organized, that blind guessing tends to work remarkably well. Personally I like the path module _a lot_, though I'm sure a thorough once-over from c.l.py and python-dev, via a PEP, can only make it better and smooth out hidden rough edges and corner cases. But I'll be very happy if it does go into the stdlib in the future. Just my .02. Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: A Module on Time & Date
Robert Maas, see http://tinyurl.com/uh3t wrote: >> From: Robert Kern <[EMAIL PROTECTED]> >> As you can see in the datetime documentation, the module was introduced >> in Python 2.3. I recommend updating your Python installation. > > What do you mean "your"?? I don't have any Python installation of my > own. All I have is what this small local ISP provides on its Unix shell > machine which I share with hundreds of other users. There's no way I > can install a new version of anything on the system account. > Your recommendation will be disregarded as total crap. You might also consider learning how to find answers to all your problems by yourself in the future, as this kind of response to a perfectly reasonable, valid suggestion pretty much ensures that people won't be terribly inclined to help you in the future. Robert's recommendation was valid, to the point, and perfectly feasible. As Skip further indicated, it's trivial to add your local python; you can also keep local modules (without a full python) in your own account and configure $PYTHONPATH. Your response was rude and stupid. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
er division or modulo by zero ** Oops, IPython crashed. We do our best to make it stable, but... A crash report was automatically generated with the following information: - A verbatim copy of the traceback above this text. - A copy of your input history during this session. - Data on your current IPython configuration. It was left in the file named: '/home/fperez/.ipython/IPython_crash_report.txt' If you can email this file to the developers, the information in it will help them in understanding and correcting the problem. You can mail it to Fernando Perez at [EMAIL PROTECTED] with the subject 'IPython Crash Report'. If you want to do it now, the following command will work (under Unix): mail -s 'IPython Crash Report' [EMAIL PROTECTED] < /home/fperez/.ipython/IPython_crash_report.txt To ensure accurate tracking of this issue, please file a report about it at: http://www.scipy.net/roundup/ipython (IPython's online bug tracker). [END IPYTHON CRASH PRINTOUT] The point is that something like this: - gives an experienced user a lot of information to track down the bug if they feel like it. - but also gives the raw newbie an easy solution: just mail me that auto-generated crash file and forget about it. In fact, I've received over the years many tracebacks with enough detail for me to fix a problem in ipython (or to code defensively against broken third-party libs or bugs in the stdlib). And many of these problems could only be reproduced with user data I had no access to, but the traceback has enough detail that I can often understand the problem and fix it just based on that. This approach has worked very well for me over the years, and these crash report emails have become fortunately rather rare as of late :) If you are interested, just get ipython and grab the files for this, it's all BSD licensed. You can also browse the SVN repo here if you want to look at the code: http://ipython.scipy.org/svn/ipython/ipython/trunk/IPython/ The relevant files are ultraTB.py and CrashHandler.py. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
Paul McNett wrote: > Fernando Perez wrote: >> If you are interested, just get ipython and grab the files for this, it's >> all >> BSD licensed. You can also browse the SVN repo here if you want to look at >> the code: >> >> http://ipython.scipy.org/svn/ipython/ipython/trunk/IPython/ >> >> The relevant files are ultraTB.py and CrashHandler.py. > > Thanks Fernando, consider your excellent code stolen! :) I'll probably > make a flag that defaults to ultraTB but that can also be set to leave > sys.excepthook as-is. Best of both worlds! Glad to be of use! I should probably ship this standalone, as I'm sure a lot of projects could use it, and the tracebacks are a hell of a lot better than what you get with python's default printouts. So little time... By all means contact me with complaints/bugs if you run into problems with this code. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Dabo in 30 seconds?
Paul McNett wrote: > I've done things like this in the past, in my own Visual Foxpro > framework. In that situation, I had enough control over the deployment > to also ship a small smtp client, and automatically email the error > without requiring any interaction at all. Clients were impressed when > I'd already have a fix for the problem before they even notified me of > the issue! Well, I thought about doing the same, which is easy since python already has smtplib built into the stdlib. I was just lazy and didn't do it. Though I would not implement it to send things silently without user acknowledgement. Since ipython is not installed by me on user machines (your situation was obviously different), I prefer to notify users of things about to be done first, in case they'd rather not have it 'call home'. But it would be a nice enhancement to add the option for auto-emailing in case of trouble. -- http://mail.python.org/mailman/listinfo/python-list
Re: interpreter frame
Peter Hansen wrote: > Leo wrote: >> Good try, but that doesn't seem to work either. Maybe I should have >> emphasized that what I really want is the line of code, as opposed to >> the entire frame. > > Ah, it wasn't clear from your first post that you were specifically > interested in a line you entered at the *interactive prompt*. The word > "interpreter" is sometimes applied to the virtual machine, so I thought > you just wanted the current frame inside an application. > > For the "interactive interpreter", I doubt the line of code that you are > executing is preserved anywhere (at least not in a supported, documented > fashion) as source, so I don't think there's a simple way to get at it. > Certainly not (I believe) through the frame or code object. Maybe > checking the source will lead to a hack solution... If using the mock interpreter in code.py (in the stdlib), the object's .buffer attribute holds that info as a list of lines. IPython exposes it publicly via its custom exception handlers mechanism (some details here: http://www.scipy.org/wikis/featurerequests/IPython). Such a buffer must also exist in the CPython interactive interpreter, but I don't think it's accessible in any way via Python-level functionality (it's most likely an internal C variable). But some perusing of the C sources could indicate a way to get to it, I'm just not familiar with that particular code. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Traceback Questions
ncf wrote: > I'm just beginning with tracebacks, building off of what I see in > asyncore's compact_traceback code, in order to hopefully store all the > values from the location in which the exception occured. > > I'm actually trying to make this into a python bug report system for my > current project, and am seeking advice on how to use sys.exc_info()[2] > better (the traceback element) > > Does anyone have any advice on how I'd preform a traceback-based > bugreport-like system? The more I work on this, the more I'm confusing > myself. :\ You may want to look at ipython's CrashHandler system: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/CrashHandler.py It does all of what you've described in your post automatically. Some of it is ipython-specific, but it should be easy enough to tweake it for your needs. For download links (the above is an SVN source browsing link): http://ipython.scipy.org At some point I should really abstract this out, there seems to be a need for it out there. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Precise timings ?
Madhusudan Singh wrote:
> Madhusudan Singh wrote:
>
>> Hi
>>
>> I am using time.clock() to get the current time of the processor in
>> seconds. For my application, I need really high resolution but currently
>> seem to be limited to 0.01 second. Is there a way to specify the
>> resolution (say 1-10 microseconds) ? My processor is a 1.4 MHz Intel
>> processor. Surely, it should be able to report times a few (or at least
>> 10) microseconds apart.
>>
>> Thanks.
>
> Correcting a typo (1.4GHz, not 1.4 MHz).
>
> And I am using Linux.
Then, this may be handy to give you an idea of the resolution you can expect at
the python level (i.e., without writing extension code). Feel free to add
fancier statistics if you actually need them:
planck[python]> cat tdelta.py
#!/usr/bin/env python
"""quick and dirty test for time deltas. Under Linux, this is best done
using time.time() instead of time.clock()"""
import commands
from time import time
npts = 50
times = [-(time()-time()) for i in xrange(npts)]
print commands.getoutput('egrep "MHz|model name" /proc/cpuinfo')
print 'Min. time delta :',min(times),'s'
print 'Max. time delta :',max(times),'s'
print 'Avg. time delta :',sum(times)/float(npts),'s'
print 'Num. of timings :',npts
#
For example, on my system:
planck[python]> ./tdelta.py
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
cpu MHz : 2794.365
Min. time delta : 2.86102294922e-06 s
Max. time delta : 9.05990600586e-06 s
Avg. time delta : 3.38554382324e-06 s
Num. of timings : 50
Cheers,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: job scheduling framework?
Larry Bates wrote: > Google turned up these links that might be of interest: > > http://www.foretec.com/python/workshops/1998-11/demosession/hoegl/ > http://www.webwareforpython.org/Webware/TaskKit/Docs/QuickStart.html > http://www.slac.stanford.edu/BFROOT/www/Computing/Distributed/Bookkeeping/SJM/SJMMain.htm > > Larry Bates > > > Chris Curvey wrote: >> Has anyone seen a simple open source job-scheduling framework written >> in Python? I don't really want to reinvent the wheel. All I need is >> the ability to set up a series of atomic "jobs" as a "stream", then >> have the system execute the jobs in the stream one-at-a-time until all >> the jobs in the stream are complete or one of them reports an error. >> >> (If it tied into a really simple grid-style computing farm, that would >> be worth double points!) In addition to Larry's links, this might also be of interest: http://directory.fsf.org/science/visual/Pyslice.html Not exactly the same, but I suspect it may be useful. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating BibTex files with XdkBibTeX
Rob Cowie wrote: > I'm looking for a module that is able to create valid BibTex documents. > I'm currently using string substitution to create the content, but it > is not validated in any way. > > The only BibTex creation module available in Python (that I can find) > is XdkBibTeX > (http://artis.imag.fr/Membres/Xavier.Decoret/resources/xdkbibtex/). It > is a python wrapper around a C library. > > Has anyone used this? More interestingly to me... has anyone > successfully installed it on Mac OS X? > > Also, can anyone suggest an alternative? http://pybliographer.org/ Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Detailed traceback
Echo wrote: > I have been working on handling unhanded exceptions and making a > detailed print out of the traceback after the exception. I found that > traceback.extract_tb worked nice and was quite simple. > > During my searching around I found out that it might be possible to > get the variables and their respective values for each frame. I found > this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52215 to > be extremely helpful. > > My only problem with that is that there appears to be no way to get > the line of code for a frame. > > So I was wondering if it was possible to get the line of code for a frame. You might not want to reinvent that particular wheel from scratch. While not rocket science, getting locals/globals correctly requires relatively careful code (it took me quite a few tries to get it right in all possible cases).. IPython's ultraTB module does everything you're asking for, and its CrashHandler module even wraps the whole thing into a tidy file ready for email to the developers. Feel free to use it, it's all BSD licensed after all. Cheers, f ps - suggestion for an enterprising user looking for a project: clean up ultraTB a little, isolate its ANSI terminal dependencies better (probably wrapped up in an abstract markup for coloring), and package it standalone. This question pops up every two weeks here, this makes me suspect that the need for better traceback printing than the primitive stuff supplied by the stdlib is real. Since ultraTB is just an offshoot of cgitb, it would be a nice way to give back to the stdlib. I'll be glad to help (though it's easy), but right now I just don't have the time to do it myself. -- http://mail.python.org/mailman/listinfo/python-list
Re: working with VERY large 'float' and 'complex' types
Todd Steury wrote: > Greetings Python'ers: > > I'm just an amature who occasionally uses Python for complex mathematical > models. The current model I'm working with occasionally generates really > large numbers that are either "float" or "complex" types. These numbers are > so large that I either get an overflow error, or some funky code like #INF > or 1.#INDj. However I really need these numbers to be calculated (although > precision isn't key). Is there a way to get python to increase the size > limit of float and complex numbers? I should mention that I'm using a lot of > pre-made modules and functions like math.exp() and scipy.special.erf() that > don't seem to be able to use available types like "Decimal" or "FixedPoint" > (especially since these don't seem to handle complex numbers). Python floats are C doubles underneath, so you're stuck. You need extended numeric types. Decimal is slow as molasses, and was not designed for mathematical work (rather for finance-type fixed-point work). Use this instead: http://calcrpnpy.sourceforge.net/clnumManual.html Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Claudio Grondi wrote: > It works for me as it is now, so probably it is better to wait for the > next release of IPython with a cleaner implementation of color > schemes before further efforts towards support for choosing > of background colors for each colorized text output in IPython > via extension of Console.py of the readline module. Just to clarify something: there's essentially zero chance that the next ipython version will provide for user-level color scheme customizations in a clean, friendly way. I simply have more important improvements I need to work on, with a very finite amount of time for it all. If you send me a patch, I'll be delighted to include it, but otherwise this will take a back seat. The main reason for this is that I'm starting to play with a rewrite of the config file system, to move away from a special plain text format, into using regular python files. This will bring multiple advantages, and once a true python syntax is available to users, these kinds of changes can be allowed with a far cleaner interface than the hacks required right now. So for now, I'd suggest you live with the hacks, while a better, permanent solution arrives. But don't expect that improvement right away. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: empty classes as c structs?
Steven Bethard wrote: > The complications with attribute hiding is one of main reasons I've > tried to minimize the number of methods associated with Bunch... in order for bunches to be fully useful in general, open contexts, I think that number of methods should be exactly zero (at least without leading underscores). Otherwise, as soon as someone loads a config file into a bunch and they assign randomname_which_you'd_used, the whole thing breaks. I see two ways to implement additional (needed) functionality into bunches: 1. The class/staticmethod approach. This has clean syntax, though it may make inheritance issues tricky, I'm not too sure. 2. To break with pythonic convention a bit, and make the public API of Bunch consist of methods which all start with a leading _. You can even (via __setattr__ or metaclass tricks) block assignment to these, and state up front that Bunches are meant to hold public data only in attributes starting with a letter. I think that would be a reasonable compromise, allowing you to do: b = Bunch() b.update = 'yes' b._update(somedict) b.copy = 'no' c = b._copy() # BUT: c._update = 'no' ## an exception is raised etc. It's not very pretty, and it does break with pythonic convention. But a Bunch class which simultaneously provides certain non-trivial functionality (otherwise the usual 'class Bunch:pass' idiom would be enough), while allowing users to store arbitrarily named attributes in it, is inevitably going to need to play namespace tricks somewhere. FWIW, I personally could live with #2 as an acceptable compromise. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython colors in windows
Claudio Grondi wrote: > Hi, > > I have just updated previously announced > and uploaded to > http://people.freenet.de/AiTI-IT/Python/Console.py > version > of Console.py because I was not satisfied with > it (it didn't support arbitrary ANSI escape > sequences for setting text colors ...) I'd suggest you post some of this info, once you hash out the details with Gary, to the ipython-users list. I'm sure others there would appreciate your efforts towards enhancing the functionality available to win32 users. Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IDLE history, Python IDE, and Interactive Python with Vim
Ashot wrote: > yup, this is why I've been using it, its (almost exactly :) what I was looking > for. I had tried it before, but was reluctant to use it because the windows > terminal is not very appealing. Some things I've noticed so far that I think > could be improved, some of which are minor but annoying: I should note that I hardly use %edit myself, it's something that was added at the request of users, and is an OK facility for quick and dirty work. But getting such a system to work reliably in all cases, with the import/execfile/reload issues at play, is really not easy. Especially because it's not even completely clear what the 'right' behaviour should be. %edit makes a few educated guesses, but that's it. My personal coding environment consists of a permanently open editor with multiple files open (XEmacs in my case), and an ipython session open. In ipython, I use %run to run test code, and when said top-level test code relies on modules which are also being changed, I simply put into the top-level scripts reload() statements. This gives me the ipython tracebacks, experimentation, tab-exploration of objects, etc, while I have the full power of Xemacs for the real editing work. IPython is NOT an IDE, so I think it's important to understand its limitations to make the best possible use of it. Perhaps I haven't done a very good job of outlining this to users, I don't know. > edit doesn't work with classes even though it says it should, you have to > point it to a function in the class (perhaps only in windows) > > under windows vim/gvim doesn't jump to the line of the function.. you said > that this should work in vi, but I'm guessing its a Windows thing Works for jed/vim under linux, that's about as much as I know. Probably a win32 thing, as you say. > **the biggest problem for me is edit forgets code in which there were errors. > for example:"ed" type some nonsense, and ed -p doesn't remember. Thats > putting an awful lot of pressure on getting the syntax right everytime =] > Perhaps I am missing something here? Fixed. Will be in the next release, which will probably come out soon (I found an unrelated crash case, and I consider crashes release-triggering bugfixes). > it would be really great if the code executed on save rather than exit, but > I'm not sure if this is possible. This would be very useful for people using > an editor not in the console.. that way you wouldn't have to keep > opening/closing new editor windows. not possible in a cross-platform, cross-editor way. > this isn't a big deal, but it would be nice if there was an easy way to refer > to the entire history (for edit/save/etc) %hist has options to print as many lines as you want. And the %log* commands will dump all of your history straight to a file, and continue recording from then on. > would be nice if you could send stuff to the clipboard. Do you have a linux/OSX/win32 way to do it? If so, I'll gladly include it. Under *nix, mouse-highlighting copies to the X11 primary selection, which I can then paste anywhere with the middle button. > There are a few other things I'm probably forgetting, but having said all > that, I've come off a little negative here. I really like IPython so far, its > got all the things I was looking for, thank you very much for your work. If I > have the time in the future I would definately contribute to this project. No problem, I appreciate the comments. Fair, honest criticism can only make a project better. Note, however, that I _strongly_ suggest you post this kind of stuff on the ipython list. While I monitor c.l.py via gmane, I'm not subscribed and sometimes I'm too busy to read it for weeks at a time, so there's a very good chance I'll simply miss ipython-related posts here. The ipython lists, on the other hand, I keep a close eye on :) Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IDLE history, Python IDE, and Interactive Python with Vim
Ashot wrote: > Sorry, a few more things I forgot to mention having to do with editing > multiline entries in the console: > > Autotab setting doesn't seem to have any effect, I have to type "ctrl-o" > manually I've noticed it doesn't work under win32. It's fine under *nix. There's only so much Gary can do with his readline supplement in a win32 environment, I'm not sure if this is something which he could add, you'd have to contact him directly. This would require support for insertions into the current line, which may not even be possible in a windows terminal, I just don't know. > Is there a setting that treats multiline entries as a single command, as IDLE > does? In otherwords, allowing you to edit the entire entry, going up to > previous lines, and treating as one when cycling through the history? It > seems like ipython recognizes these through the hist command, but not when > editing or cycling. This is impossible in a line-oriented terminal program. What you are asking for requires 2-d cursor control, which can only be provided in a gui environment, or with curses in a terminal (or with custom terminal handling code). Basically, it means writing a complete screen-handling program, which is far more than ipython can do. I keep trying to start an internal ipython cleanup, so it could be embedded into a gui environment. Once that happens, it may be possible to use idle or pycrust but with the ipython engine. Within the design constraints of not taking over the terminal with a curses (or similar) environment, restricted to onlw raw_input() communication with the user, what you are asking is a technical impossibility. > Is it possible to use the "set editing-mode vi" option in ipython since it > uses readline? From reading online, it seems like this should be possible, > however it doesn't work for me. It works in bash, but once I enter either > ipython or just regular python the keybindings don't work anymore. I don't know if this works even under *nix, since I don't know if the python readline library wraps this part of GNU readline. I _do_ know that python only wraps a subset of GNU readline, so I wouldn't be surprised if this wasn't included. It is not something specific to ipython, you'd have to ask the readline developers directly. Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Hack with os.walk()
Michael Spencer wrote: > The path module by Jorendorff: http://www.jorendorff.com/articles/python/path/ > > wraps various os functions into an interface that can make this sort of thing > cleaner Wow, many thanks for the pointer. This has to be one of the single most useful small python modules out there, and it seems to address (from reading the docs) most of the things that annoy the hell out of me when doing filesystem scripting in python. I've always felt that filesystem-related scripting, in python, is unnecessarily complicated. It is perhaps the only part of the stdlib (note: I don't claim to have used it all) which positively, unfailingly, manages to piss me off every time I use it. The main problem is that things which are conceptually related, are scattered all over the stdlib. Do you know, off the top of your head, whether a file-related function is in os, os.path, shutil, glob, dircache, etc? I've actually considered writing a PEP requesting this, but such an effort would obviously mean writing an implementation. Not hard, but I just don't have the time for it. Perhaps this path.py could be considered for inclusion in the stdlib? I've only read the page linked above, so perhaps it can use some polishing. But it certainly looks like a big improvement over the scatterblast which the stdlib is on this particular topic. Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Hack with os.walk()
Robert Kern wrote: > Fernando Perez wrote: > >> Perhaps this path.py could be considered for inclusion in the stdlib? I've >> only >> read the page linked above, so perhaps it can use some polishing. But it >> certainly looks like a big improvement over the scatterblast which the stdlib >> is on this particular topic. > > I'm pretty sure this has been discussed at some point. I completely > forget the results of said discussion (except the part where it wasn't > going in yet, although you can't really call that "remembering" so much > as "deducing from the current state of affairs"). It's probably one of those things which is not enough of a bother for anyone to stop and commit the effort to fix it. After all, working around the problem isn't that hard, since all the functions are there (somewhere), and their poor interfaces can typically be lived with. But the code examples in path.py really feel like a breath of (pythonic) fresh air compared to the stdlib in this regard. Care to champion it ? ;) Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: graphing
Jan Rienyer Gadil wrote: > i'm currently using python 2.3(enthought edition) on win 2000/xp. > i'm using boa constructor on the GUI part and matplotlib 0.71 on > plotting the graph. You should post this on the matplotlib list directly, where your chances of a reply are much better. I use matplotlib, but not in the context of GUI embedding, so I can't help. best, f -- http://mail.python.org/mailman/listinfo/python-list
[ANN] IPython 0.6.11 is out.
Hi all, I'm glad to announce the release of IPython 0.6.11. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (for Python 2.3 and 2.4, built under Fedora Core 3), plus source downloads (.tar.gz). We now also have a native win32 installer which should work correctly for both Python 2.3 and 2.4. NOTE: Win32 users who grabbed the 0.6.11 which I put in testing last week should still update, since today's release is actually quite different, and it has a few win32-specific fixes (plus the big new backgrounding feature). Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. Release notes - As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. * A new subsystem has been added to IPython for background execution (in a separate thread) of commands and function calls. This system is by no means perfect, and some of its limitations are unavoidable due to the nature of python threads. But it can still be useful to put in the background long-running commands and regain control of the prompt to continue doing other things. The new jobs builtin has extensive docstrings, and the new %bg magic complements it. Please type %bg? and jobs? for further details. The user-level API of this system is brand new, so I am very open to suggestions and comments. While a threads-based model has limitations, this is also a testbed for future integration into ipython of other models of background execution, including parallel processing both on local (multiprocessor/multicore) machines and on remote clusters. So please consider this an exploratory feature where we can test these ideas and better understand what works and what doesn't. This system was inspired by discussions with Brian Granger <[EMAIL PROTECTED]> and the BackgroundCommand class described in the book Python Scripting for Computational Science, by H. P. Langtangen: http://folk.uio.no/hpl/scripting (although ultimately no code from this text was used, as IPython's system is a separate implementation). * Tab completion now shows all possible completions, both for python names and files/directories. This is different from the old behavior, but in practice much more convenient (thanks to John Hunter for the request). * The readline_omit__names rc option now allows you to fine-tune the behavior of tab-completion. You can filter out names starting with one underscore or two separately. If set to 1, you only filter double-underscore names (like before), but if set to 2, you also filter out single-underscore names. Thanks to a patch by Brian Wong <[EMAIL PROTECTED]>. * Improvements for win32 users continue. The installer bug for 2.4 has been fixed by the Python team, so the provided binary installer should now complete without problems (let me know otherwise). Just in case, a manual post-installer for win32 still ships with the .tar.gz sources, though it should never be needed. Gary Bishop also squashed a number of readline bugs, so if you update to his most recent release from http://sourceforge.net/projects/uncpythontools you should benefit from fully correct source highlighting under Win32. Thanks to Vivian De Smedt, autoindent now also works under win32. As far as I know, at this point (for the first time ever, fingers crossed...), all of ipython's features exist in a win32 environment. Many thanks to all the patient users who have helped with this task. I would appreciate reports of any problems from Win32 users. * Fix issue28 in the bug tracker by disabling the startup output traps. This subsystem, while nice when it works (it organizes startup error messages neatly) can lead to mysterious, impossible to debug problems during initialization. * Fix 'ed -p' not working when the previous call produced a syntax error. * Fix crash when inspecting classes without constructor. * Other small fixes and cleanups. Enjoy, and as usual please report any problems. Regards, Fernando. -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] IPython 0.6.11 is out.
Ville Vainio wrote: > Warning - if you are upgrading and have an old pysh.py dangling around > in $HOME/.ipython, be sure to delete it. The old version is > incompatible with the new ipython. Just to clarify: you need to delete ONLY the old pysh.py, not your entire $HOME/.ipython/ directory. You can then update from the pysh.py which comes with the ipython distribution, typically in sys.prefix/site-packages/IPython/UserConfig Sorry about not putting this in the release notes, I didn't notice it myself. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: huge help for interactive python
David S. wrote: > If you are using ipython on Windows then you will > have made sure you have Gary Bishop's readline > library as instructed in the ipython install > directions found at: > http://ipython.scipy.org/ [...] Thanks, very handy. I just reposted your message to the ipyhton-users list, since others may find it useful there. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: recommended way of generating HTML from Python
Michele Simionato wrote: > What is the recommended way of generating HTML from Python? I know of > HTMLGen and of > few recipes in the Cookbook, but is there something which is more or > less standard? I'm also an htmlgen user, but it's getting a bit long in the tooth, and the installation is not very clean (pre-distutils). I keep an eye out for alternatives, here's one (which I haven't looked at yet): ## htmldata 1.0.6 is available. http://oregonstate.edu/~barnesc/htmldata/ The htmldata module allows one to translate HTML documents back and forth to list data structures. This allows for programmatic reading and writing of HTML documents, with much flexibility. ## I could swear that I also saw another recent email announcing an htmlgen alternative, but no amount of googling or digging through my email could turn it up. I think it was in the last month or so, and probably on the python-announce list, but looking through the archives I can't find it. Maybe my memory is playing tricks on me. > Also, are there plans to include a module for HTML generation in the > standard library? > I really would like to see some standardization in this area. I would too. The HTMLgen model is quite nice and clean (at least for my simple uses), but I'd use anything, as long as it's included by default and supported. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
[ANN] IPython 0.6.12 is out.
Hi all, I'm glad to announce the release of IPython 0.6.12. This is mainly a bugfix release. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (for Python 2.3 and 2.4, built under Fedora Core 3), plus source downloads (.tar.gz). We now also have a native win32 installer which should work correctly for both Python 2.3 and 2.4. Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. Release notes - As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. * New hooks system. This can be considered the first step in cleaning up ipython to expose its internals in a more rational manner. IPython/hooks.py contains the hooks which are meant to be easily overridden by users for customizations. Currently only the editor hook (called by %edit) exists, but a framework is in place. * Fix a subtle bug with corrupted init files under win32, thanks to Ville Vainio for trackign this. * Fix for Debian, which recently removed the profiler module from the default python distribution and moved it to non-free. * Allow empty and left-aligned output prompts, if users so want them. * New %time magic to time statements and expressions. It reports CPU and wall clock time. * Other small fixes and cleanups. Enjoy, and as usual please report any problems. Regards, Fernando. -- http://mail.python.org/mailman/listinfo/python-list
Re: computing a weighted sum
[EMAIL PROTECTED] wrote: > Suppose I have a list of n floats x and a list of n floats w and I want > to compute x[0]*w[0] + .. + x[n-1]*w[n-1]. > > Is there some elegant expression (perhaps using lambda) to have it done > in one statement ? As in : > y = lambda x,w : ... > > I ask because the way I am doing it now : > y = 0 > for i in range(0,n): y += x[i]*w[i] > > doesn't seem very pythonic :) > > Thanks, > Andrei > import Numeric print Numeric.dot(x,w) Best, f -- http://mail.python.org/mailman/listinfo/python-list
ANN: IPython 0.6.5 is out
Hi all, I'm glad to announce that IPython 0.6.5 is finally out. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs for Python 2.2 and 2.3, plus source downloads (.tar.gz and .zip). Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. I'd promised that 0.6.4 would be the last version before the cleanup, but Prabhu Ramachandran managed to resucitate the GUI threading support which I'd worked on recently, but disabled after thinking it could not work. It turns out we were very close, and Prabhu did fix the remaining problems. Since this is a fairly significant improvement, I decided to make a release for it. In the process I added a few minor other things. *** WHAT is IPython? IPython tries to: 1. Provide an interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. Serve as an embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. Offer a flexible framework which can be used as the base environment for other systems with Python as the underlying language. *** NEW for this release: As always, the complete NEWS file can be found at http://ipython.scipy.org/NEWS, and the whole ChangeLog at http://ipython.scipy.org/ChangeLog. * Threading support for WXPython and pyGTK. It is now possible (with the -wthread and -gthread options) to control wx/gtk graphical interfaces from within an interactive ipython shell. Note that your wx/gtk libs need to be compiled with threading support for this to work. There is also experimental (but brittle) support for running Tkinter graphical interfaces alongside with wx or gtk ones. * New -d option to %run, for executing whole scripts with the interactive pdb debugger. This allows you to step, watch variables, set breakpoints, etc, without having to modify your scripts in any way. * Added filtering support for variable types to %who and %whos. You can now say 'whos function str' and whos will only list functions and strings, instead of all variables. Useful when working with crowded namespaces. (For some reason I forgot to document this in the ChangeLog). * Added ipython.el to the end-user distribution, for (X)Emacs support, since now the official python-mode.el from http://sourceforge.net/projects/python-mode has all the necessary fixes for ipython support (in CVS at this moment). * Other minor fixes and cleanups, both to code and documentation. Enjoy, and as usual please report any problems. Regards, Fernando. -- http://mail.python.org/mailman/listinfo/python-list
Re: memoize factorial example (was Re: decorators ?)
Terry Reedy wrote: > > "Daniel 'Dang' Griffith" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> But the factorial example on the wiki has a defect. It incorrectly >> calculates factorial(0) as 0, when it should be 1. > > This is a matter of definition, and definitions apparently differ. fact(0) > == 0 is a backward projection from the definition f(1) = f(2) = 1 in > 1-based systems, which is the context for the rabbit problem in which the > first year is year 1, not year 0. Disagreement is not defect. No, fact(0)==1 simply because any proper definition of a factorial has to match up with the gamma function (offset by one) at all non-negative integers. So there's no room for any ambiguity here. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: 3D plotting library / OpenGL
Andrew Dalke wrote: > I've been looking for a decent 3D plotting library with support > for user selection that works under OpenGl, preferable with wxPython. > > For this first project I need to do a 3D scatter plot with > different colors and glyphs (spheres, crosses, etc.) for the points. > The axes will be labeled and I would like both mouseover and > mouse click selection. There will be at most 2,000 points. > > I've found several for making graphs, like DISLIN, but most > don't offer interactivity. I spent many hours trying to get > VTK working on my Mac under both native and X GUI toolkits, > without success. SciGraphica seems close, but it has the > Gtk requirement. I'd seriously recommend you look at VTK again. I've done exactly what you are describing with Mayavi: http://amath.colorado.edu/faculty/fperez/faults/ Disregard the timing info, it's old and with some fixes to MayaVi I wrote (available in current CVS), and a tweaked glyphs user module (which I can send you if you want it), the speed is extremely fast even for fairly large datasets. Mayavi is finkable, though after using fink to pull it in (so you get vtk and friends) you might want to update to CVS to get some of the recent fixes which I think are not yet on the fink version. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: memoize factorial example (was Re: decorators ?)
Fernando Perez wrote: > No, fact(0)==1 simply because any proper definition of a factorial has to > match > up with the gamma function (offset by one) at all non-negative integers. So > there's no room for any ambiguity here. I should have added a link to the ever-useful mathworld: http://mathworld.wolfram.com/Factorial.html This has as much detail about n! and Gamma(z) as you'll ever want to know :) Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Rationale behind the deprecation of __getslice__?
Hi all, I was wondering if someone can help me understand why __getslice__ has been deprecated, yet it remains necessary to implement it for simple slices (i:j), while __getitem__ gets called for extended slices (i:j:k). The problem with this approach, besides a bit of code duplication, is that classes which implement slicing must now do runtime type-checking inside __getitem__. Here's a trivial example: import types class Vector(list): def __init__(self,arg,wrap=0): ''' If arg is an integer, make a new zero vector of length n. Otherwise, arg must be a python sequence or another vector, and a new (deep) copy is generated. ''' if isinstance(arg,int): list.__init__(self,[0.0]*arg) else: list.__init__(self,arg) def __getitem__(self,key): """called for single-element OR slice access""" if type(key) is types.SliceType: return Vector(list.__getitem__(self,key)) else: return list.__getitem__(self,key) def __getslice__(self,i,j): """Deprecated since 2.0, but still called for non-extended slices. Since extended slices are handled by __getitem__, I'm just deferring to that one so all actual implementation is done there. Why this is not the default (since they deprecated __getslice__) is beyond me.""" return self.__getitem__(slice(i,j)) print 'a is a vector' a = Vector(5) print a print type(a) print print 'b is a slice of a' b = a[1:3] print b print type(b) print print 'c is an element of a' c = a[1] print c print type(c) What bugs me is that typecheck for slicing which seems to be necessary inside of the __getitem__ method. I have the feeling that the code would be much cleaner if I could simply use __getslice__ for slices and __getitem__ for items, and that bundling the two in this hybrid mode is reall ugly and unpythonic. Am I just missing something? Thanks for any help, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Rationale behind the deprecation of __getslice__?
Fernando Perez wrote: > Hi all, > > I was wondering if someone can help me understand why __getslice__ has been > deprecated, yet it remains necessary to implement it for simple slices (i:j), > while __getitem__ gets called for extended slices (i:j:k). [...] > def __getitem__(self,key): > """called for single-element OR slice access""" > if type(key) is types.SliceType: > return Vector(list.__getitem__(self,key)) > else: > return list.__getitem__(self,key) I just realized that the type check is cleaner if done via def __getitem__(self,key): """called for single-element OR slice access""" if isinstance(key,slice): return Vector(list.__getitem__(self,key)) else: return list.__getitem__(self,key) Still, the core of my question remains. TIA, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Rationale behind the deprecation of __getslice__?
Steven Bethard wrote:
> Fernando Perez wrote:
>> I was wondering if someone can help me understand why __getslice__ has been
>> deprecated, yet it remains necessary to implement it for simple slices
>> (i:j), while __getitem__ gets called for extended slices (i:j:k).
>
> I don't think this is true -- everything goes to __getitem__:
>
> >>> class C(object):
> ... def __getitem__(self, *args, **kwds):
> ... print args, kwds
> ...
> >>> c = C()
> >>> c[1]
> (1,) {}
> >>> c[1:2]
> (slice(1, 2, None),) {}
> >>> c[1:2:-1]
> (slice(1, 2, -1),) {}
Not if you subclass builtin types like list:
In [6]: class mylist(list):
...: def __getitem__(self,*args,**kwds):
...: print 'mylist getitem'
...: print args,kwds
...:
In [7]: a=mylist()
In [8]: a[1]
mylist getitem
(1,) {}
In [9]: a[1:2]
Out[9]: []
In [10]: a[1:2:3]
mylist getitem
(slice(1, 2, 3),) {}
I did this testing, which is what forced me to implement __getslice__
separately in my little example, to satisfy calls with simple i:j slices.
Best,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: Rationale behind the deprecation of __getslice__?
Steven Bethard wrote: > Fernando Perez wrote: >> classes which implement slicing must now do runtime type-checking inside >> __getitem__. > > Just in case you thought that they wouldn't have to do runtime > type-checking otherwise: > > >>> class C(object): > ... def __getitem__(self, x): > ... print type(x), x > ... [...] > You can put just about anything in a __getitem__ call. Do you really > want a method for each of the variants above? I guess that conceptually it just felt natural to me to keep separate methods for dealing with a slice (get many elements out) and other types of indexing, which I tend to think of as 'scalar' indexing. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Rationale behind the deprecation of __getslice__?
Terry Reedy wrote: > >> If no __getslice__() is found, a slice object is created instead, and >> passed to __getitem__() instead. > > The overwhelmingl most common case of a simple slice is more efficiently > done by having a separate function since no slice object is created. > a=[1,2,3] def f(): return a[0:1] > ... import dis dis.dis(f) [...] Very good point. I always forget how useful dis is, thanks. f -- http://mail.python.org/mailman/listinfo/python-list
Re: Rationale behind the deprecation of __getslice__?
Steven Bethard wrote: > Presumably the numarray code has to do quite a bit of type checking to > perform all these slicings right (and I didn't even show you what > happens when you use another array as an "index"). I'm not necessarily Yes, I know. I haven't switched to numarray because of the small-array penalty (which I can't pay in my code), but recently T. Oliphant added array-indexing to Numeric in Scipy's port. Very nifty. > saying that all this type checking is a good thing, but because people > will always find new things that they want to index by, adding > __getxxx__ methods for each of the index types is probably not the right > road to go down... Ultimately it's true that since indexing objects for multidimensional arrays will always come in packaged as a tuple, the __getitem__ method will simply have to deal with a fair bit of analysis before getting to the meat of actually returning a result. Anyway, thanks for the discussion, it clarified a few points. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
ANN: IPython 0.6.5 is out.
Hi all, I'm glad to announce the release of IPython 0.6.6. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (Py2.2 and 2.3), plus source downloads (.tar.gz and .zip). Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. Release notes - This release was made to fix a few crashes recently found by users, and also to keep compatibility with matplotlib, whose internal namespace structure was recently changed. * Adapt to matplotlib's new name convention, where the matlab-compatible module is called pylab instead of matlab. The change should be transparent to all users, so ipython 0.6.6 will work both with existing matplotlib versions (which use the matlab name) and the new versions (which will use pylab instead). * Don't crash if pylab users have a non-threaded pygtk and they attempt to use the GTK backends. Instead, print a decent error message and suggest a few alternatives. * Improved printing of docstrings for classes and instances. Now, class, constructor and instance-specific docstrings are properly distinguished and all printed. This should provide better functionality for matplotlib.pylab users, since matplotlib relies heavily on class/instance docstrings for end-user information. * New timing functionality added to %run. '%run -t prog' will time the execution of prog.py. Not as fancy as python's timeit.py, but quick and easy to use. You can optionally ask for multiple runs. * Improved (and faster) verbose exeptions, with proper reporting of dotted variable names (this had been broken since ipython's beginnings). * The IPython.genutils.timing() interface changed, now the repetition number is not a parameter anymore, fixed to 1 (the most common case). timings() remains unchanged for multiple repetitions. * Added ipalias() similar to ipmagic(), and simplified their interface. They now take a single string argument, identical to what you'd type at the ipython command line. These provide access to aliases and magics through a python function call, for use in nested python code (the special alias/magic syntax only works on single lines of input). * Fix an obscure crash with recursively embedded ipythons at the command line. * Other minor fixes and cleanups, both to code and documentation. The NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. Enjoy, and as usual please report any problems. Regards, Fernando. -- http://mail.python.org/mailman/listinfo/python-list
Re: ".>>>" is a good idea! (OT, was: Re: do you master list comprehensions?)
Kent Johnson wrote: > Keith Dart wrote: >> What I do is set Python's sys.ps1 variable to something else. I have a >> module called "interactive" that I import implicitly by shell alias: >> >> py='python -i -c '\''import interactive'\' >> >> Which, among other things, sets the prompt to "Python> " > > You can do the same thing using a PYTHONSTARTUP file - see > http://docs.python.org/tut/node4.html#SECTION00424 > > You can change the prompts with > import sys > sys.ps1 = ' >>> ' > sys.ps2 = ' ... ' You might want to look at ipython: http://ipython.scipy.org, which provides you automatically with these prompts: In [1]: for i in range(2): ...: print i, ...: 0 1 In [2]: 99*2 Out[2]: 198 In [3]: _2+1 Out[3]: 199 As a curiosity, ipython was actually born as a sys.ps1/2 hack, by assigning to these objects whose __repr__ would give numbered prompts with results caching. These days it's a full-blown pure python interpreter, not a $PYTHONSTARTUP customization anymore, but it's an interesting little historical curiosity. Especially if you start going very far with interactive customizations, you might not want to rewrite all of ipython's 15K lines of code :) Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding paths to sys.path permanently, and another problem...
Amir Dekel wrote:
> Hi everyone,
>
> I have two problems:
>
> 1. How can I keep my changes in sys.path after closing the interpreter?
As others said, use $PYTHONPATH
> 2. os.path.expanduser("~") always gives me "C:\\" instead of my
> homepath. I have tried to change my homepath in WinXP using set
> homepath(in command line), and alsaw using the "Environment Variables"
> in WinXP system properties, non helped. I really have to fix this somehow.
This is what ipython uses to try and get that information in a portable manner.
Note that it uses _winreg, which is part of the win32 extensions.
In [1]: import IPython.genutils
In [2]: psource IPython.genutils.get_home_dir
def get_home_dir():
"""Return the closest possible equivalent to a 'home' directory.
For Posix systems, this is $HOME, and on NT it's $HOMEDRIVE\$HOMEPATH.
Currently only Posix and NT are implemented, a HomeDirError exception is
raised for all other OSes. """ #'
if os.name == 'posix':
return os.environ['HOME']
elif os.name == 'nt':
# For some strange reason, win9x returns 'nt' for os.name.
try:
return os.path.join(os.environ['HOMEDRIVE'],os.environ['HOMEPATH'])
except:
try:
# Use the registry to get the 'My Documents' folder.
import _winreg as wreg
key = wreg.OpenKey(wreg.HKEY_CURRENT_USER,
"Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders")
homedir = wreg.QueryValueEx(key,'Personal')[0]
key.Close()
return homedir
except:
return 'C:\\'
elif os.name == 'dos':
# Desperate, may do absurd things in classic MacOS. May work under DOS.
return 'C:\\'
else:
raise HomeDirError,'support for your operating system not implemented.'
HTH,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: ".>>>" is a good idea! (OT, was: Re: do you master list comprehensions?)
Keith Dart wrote: > Fernando Perez wrote: > >> >> >> You might want to look at ipython: >> >> http://ipython.scipy.org, >> >> >> >> > > I did just recently install that. It looks very nice. Would make a great > interactive prompt for an IDE, as well. Glad you like it :) And yes, there are plans to clean it up so it can be easily embedded into a full-blown IDE (as well as remaining available for regular command-line use). This keeps on getting delayed by inevitable bug fixes and my very limited time, but it will happen... Best, f -- http://mail.python.org/mailman/listinfo/python-list
Bug in inspect.py for python 2.3?
Hi all, IPython has suffered quite a few problems with the inspect module in python 2.3. For these, unfortunately all I've been able to do is guard with overreaching except clauses, as I had not been able to find small, reproducible examples to pass on to the devs. But today I got a crash report from a user and I've been able to replicate this crash with a tiny script which does not depend on ipython at all. I'd like to hear from some of our resident gurus if this is really an inspect.py bug before I bother the developers with a formal bug report on SF. The script below illustrates the problem. Just run it, and you'll get a traceback coming from inside inspect.py itself. For now, I've added a guard in ipython against this failure mode, but it would be nice to fix the problem at the source if there really is one. Best, f #!/usr/bin/env python """This script triggers an exception in inspect.py This exception was crashing ipython for the input line: (lambda(x): x[0] + x[1])(3) when IPython tried to print the traceback for the user. As far as I can tell, it's a bug in inspect, since for all other kinds of calls of invalid user input, ipython works fine. But perhaps it's my fault, I'm not sure.""" import sys import inspect try: # This line is invalid, but we should be able to build exception info for # it with the usual tools. (lambda(x): x[0] + x[1])(3) except: etb = sys.exc_info()[2] records = inspect.getinnerframes(etb) for frame, file, lnum, func, lines, index in records: # The getargvalues call below blows up with an exception in inspect.py args, varargs, varkw, locals = inspect.getargvalues(frame) print 'args:',args -- http://mail.python.org/mailman/listinfo/python-list
Re: expression form of one-to-many dict?
Steven Bethard wrote: > Actually, it's even smaller now, because I've pretty much removed map > from all my code in favor of list comprehensions, which I find much > easier to read. While I agree that listcomps are more readable in most cases (and certainly for all cases with any amount of complexity in the listcomp), I still find that map is hard to beat for the simple case of a callable foo: outlist = map(foo,inlist) is still better in my book, and far more readable, than outlist = [foo(x) for x in inlist] The map form, in this case, parses instantly in my brain, while the listcomp certainly takes a few cycles. And note that I'm not talking about the typing conciseness, but about the effort for my brain. But maybe I'm just wired funny :) Since I tend to have a lot of code like this, I really cringe when I hear of a desire to do away with map altogether. I know I could rewrite it myself in all my code, but the beauty of these builtins is that they are always there... Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in inspect.py for python 2.3?
Terry Reedy wrote: > [I removed the blank lines which made it diffificult to cut and paste.] > [Here is the output (from 2.2) you forgot to include'-):] Yes, that's exactly the output I see. Note that in ipython I have had to protect ALL calls for inspect.get* functions in blanket excepts, because after python 2.3, I started getting crash reports left and right. Unfortunately they've all been generated by outside users after long interactive sessions, and never has anyone been able to give me a small example which can reproduce the problem (except for the one today). Somehow, the inspect module became massively more brittle after python2.3, because those problems never happened with 2.2 (though today's does appear with 2.2). It's really a shame that I don't have nice small test cases so we could track these bugs down. > If the same happens in 2.4, I would probably report it after looking a bit > at the inspect code and after adding a debug print before the getargvalues > call to see if the second record values looks as sane as the first set. If > you want a fix in 2.3.5, coming January, a patch would more likely get > action than just a bug report. Thanks for the note. Unfortunately, I don't have time right now to work with 2.4, I'm too swamped with other things. But it would be nice if someone else can find the time :) Regards, f -- http://mail.python.org/mailman/listinfo/python-list
lambdas vs functions: a bytecode question
Hi all, there are a couple of threads on lambdas today, which got me curious about their differences as far as bytecode goes: planck[~]|2> lf=lambda x: x**2 planck[~]|3> def ff(x): return x**2 |.> planck[~]|4> import dis planck[~]|5> dis.dis(lf) 1 0 LOAD_FAST0 (x) 3 LOAD_CONST 1 (2) 6 BINARY_POWER 7 RETURN_VALUE planck[~]|6> dis.dis(ff) 1 0 LOAD_FAST0 (x) 3 LOAD_CONST 1 (2) 6 BINARY_POWER 7 RETURN_VALUE 8 LOAD_CONST 0 (None) 11 RETURN_VALUE Can someone explain to me what the extra two bytecodes at the end of the function version (ff) are for? This is just curiosity, please note that I am NOT making any arguments pro or against lambdas, functions or anything else. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in inspect.py for python 2.3?
Peter Otten wrote: > Fernando Perez wrote: > >> I'd like to hear from some of our resident gurus if this is really an >> inspect.py bug before I bother the developers with a formal bug report on >> SF. >> The script below illustrates the problem. Just run it, and you'll get a >> traceback coming from inside inspect.py itself. For now, I've added a >> guard in ipython against this failure mode, but it would be nice to fix >> the problem at the source if there really is one. > > That is indeed a bug, and it is fixed as of > http://sourceforge.net/tracker/index.php?func=detail&aid=1005466&group_id=5470&atid=305470 Great, many thanks for the info. This way I don't bother the devs with unnecessary bug triage. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: lambdas vs functions: a bytecode question
Erik Max Francis wrote: > Fernando Perez wrote: > >> Can someone explain to me what the extra two bytecodes at the end of the >> function version (ff) are for? >> >> This is just curiosity, please note that I am NOT making any arguments pro >> or against lambdas, functions or anything else. > > It's returning None. I would guess that it's a safety net to make sure > you don't fall of the end of the function without returning anything; > that is, the code analysis is not in place to see whether it's necessary > to actually include in the bytecodes or not. Thanks, that makes sense, considering that the bytecode compiler in python does very little in the way of flow analysis. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: IPython 0.6.5 is out.
Fernando Perez wrote: > I'm glad to announce the release of IPython 0.6.6. IPython's homepage is at: Sorry, the _title_ was incorrect. 0.6.6 is indeed a new release put out today, I just copied an old title and missed the change. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: gather information from various files efficiently
Keith Dart wrote: > Aye... > > the dict.keys() line creates a temporary list, and then the 'in' does a > linear search of the list. Better would be: > > try: > dict[a].append(b) > except KeyError: > dict[a] = [b] > > since you expect the key to be there most of the time, this method is > most efficient. You optomistically get the dictionary entry, and on the > exceptional case where it doesn't yet exist you add it. I wonder if dct.setdefault(a,[]).append(b) wouldn't be even faster. It saves setting up the try/except frame handling in python (I assume the C implementation of dicts achieves similar results with much less overhead). Cheers, f ps. I changed dict->dct because it's a generally Bad Idea (TM) to name local variables as builtin types. This, for the benefit of the OP (I know you were just following his code conventions). -- http://mail.python.org/mailman/listinfo/python-list
Re: expression form of one-to-many dict?
Doug Holton wrote: > Mike Meyer wrote: > >> Personally, I'd love a language feature that let you create a function >> that didn't evaluate arguments until they were actually used - lazy >> evaluation. That lets you write the C ?: operator as a function, for >> a start. >> >> Hmmm. No, iterators can't be used to fake it. Oh well. > > That is a brilliant idea. I would suggest requesting such a feature for > Python 3.0: http://www.python.org/cgi-bin/moinmoin/Python3.0 Just as a reference, Mathematica does have such a feature, in the form of the HoldAll, HoldFirst, etc. function attributes. It can come in quite handy. I actually used it to write a little routine to auto-generate python modules for mathematica variables of certain types, without having to specify a list of strings for their names. The evaluation control allowed me to give it a very clean interface, while the equivalent python2mathematica routine requires a list of variable names (strings) as input, and plays sys._getframe tricks with it. Not very pleasant. So yes, I think it would be a really nifty feature to have, though I haven't really thought about how well it meshes (or not) with the rest of python's design. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Alex Martelli wrote: > I don't know what it IS about lambda that prompts so much dubious to > absurd use, but that's what I observed. I don't know if that plays any > role in Guido's current thinking, though -- I have no idea how much > "dubious Python" he's had to struggle with. Just a side comment, unrelated to the lambda issue: it just occurred to me that it might be very useful to have a collection of 'dubious python' available somewhere. Just as it is great for everyone to see good code in action, it is equally enlightening to see examples of bad practices (preferably with an explanation of why they are bad and the good alternatives). I suspect after your CB2 experience, you are in a uniquely well-qualified position to have such a collection handy. Whether you feel inclined to spend the necessary time assembling it for public consumption is a different story :) But I think it would be a very valuable resource, and a great way to point newbies to 'mandatory reading' before they travel down the same blind alleys for the n-th time. Cheers, and happy holidays, f -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: IPython 0.6.5 is out
Dan Christensen wrote: > Fernando Perez <[EMAIL PROTECTED]> writes: > >> * Added ipython.el to the end-user distribution, for (X)Emacs support, since >> now the official python-mode.el from >> >> http://sourceforge.net/projects/python-mode >> >> has all the necessary fixes for ipython support (in CVS at this moment). > > I've never been able to get color working when using ipython within > emacs (21.3). I just see various control codes in the *Python Output* > buffer. I'm using ipython 1.8, python-mode 4.69 from CVS and > ansi-color 3.4.5. Any suggestions? Mmh, unfortunately I'm not one of the experts on emacs by a long shot. While I use it (well, Xemacs), I know next to nothting about (x)emacs customization and troubleshooting. I'll have to suggest that you post this to the ipython-user list: http://scipy.net/mailman/listinfo/ipython-user I could post it myself, but most likely if someone can help, they'll have further questions and things to test regarding your own configuration. It's best if you can be there to actually answer directly. Sorry not to be able to help further on this matter. Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: emulating python shell
Uwe Mayer wrote:
> Hi,
>
> in an application I want to provide direct access to the python interpreter
> of the running program.
> I use rawinput() and exec() to read an input string and a self-made function
> to check wether the inputed block is closed and then execute it.
>
> When running python interactively the result of the previous statement is
> assigned to the variable "_" and commands like dir() just output their
> results to stdout.
> However, executions of the sort:
>
> exec("_ = "+command)
>
> don't work.
>
> Any ideas how to mimick python -i 's behaviour?
You can look at the code.py module in the python standard lib. It implements a
pure-python interactive interpreter from scratch, so there's no need for you
to reinvent that particular wheel. Since it's in the standard lib, you can
rely on it for deployment to external sites.
If you want something more sophisticated, and ready-made for this kind of
embedding, look at ipython: http://ipython.scipy.org. IPython is itself based
on code.InteractiveConsole, but at this point it has overridden almost all of
the methods in the base class.
Embedding it is as easy as:
from IPython.Shell import IPShellEmbed
ipshell = IPShellEmbed()
ipshell() # this call anywhere in your program will start IPython
You can have multiple embedded instances, and they can be initialized to use
anythingb
You can find further details about embedding ipython here:
http://ipython.scipy.org/doc/manual/node9.html
HTH,
f
--
http://mail.python.org/mailman/listinfo/python-list
Re: Q: Scheduling in scipy.cow
Scott David Daniels wrote: > Mathias wrote: >> Dear NG, >> >> can somebody tell me how the work packages are scheduled to the workers? >> From the code it seems to me like a a static distribution, ie each >> worker gets the same amount of work, not taking into account if a faster >> worker already finished all work packages. >> >> Thanks, >>Mathias >> >> PS: Is there a better NG for scipy related questions, espescially >> scipy.cow? >> > I don't know the general newsgroup name, but: > gmane.comp.python.scientific.user > or gmane.comp.python.scientific.devel > > on news.gmane.org are the places I watch for scipy stuff. These are the gmane interfaces to the scipy user/dev lists, which can be found here in regular mailing list form: http://www.scipy.org/mailinglists/ Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Alex Martelli wrote: > the coverage of Twisted and adding just a few things (numarray -- > perhaps premature to have it _instead_ of Numeric, though; dateutils, You might want to keep in touch with the scipy/numarray gang on this particular topic. An effort is currently under way to make scipy work with numarray, and matplotlib already works with numarray out of the box. These two facts will, I think, greatly accelerate the adoption of numarray and the transition away from Numeric. There are a few people (like me, unfortunately), who can simply not use numarray because of the small array instatiation overhead. But that subcommunity tends to know enough to be able to deal with the problems by itself. Since numarray is indeed the long-term array core for Python, I think the book would be better off by covering it. Numarray is actively developed, and vastly better documented than Numeric. A mention of the particular problems with numarray might be a good idea, so that readers are aware of Numeric and where it may still be preferable to numarray, but with the understanding that it's a (shrinking) niche. Hopefully one day that niche will shrink to zero, but that is going to take time and work. Finally, I think in this section a mention of the overall scipy project would be a good idea. Scipy is the central meeting point for most scientific computing projects in python, and therefore a natural reference for most users of numarray/numeric. Amongst other useful things at the scipy site, there's a community maintained wiki of links to python-based projects of scientific interest: http://www.scipy.org/wikis/topical_software/TopicalSoftware Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Steven Bethard wrote: > I get the correct output, but if you run this yourself, you'll see that > the numbers 1 through 10 aren't printed in sync with the writes (i.e. > every half second); they're all printed at the end. Could someone > explain to me why this happens, and how (if possible) I can get the > numbers printed in sync with the appends to the list? This is just a shot in the dark, as I'm quite ignorant of threading details. But what happens if you try adding a sys.stdout.flush() call after the print statement in your custom update() method? It may just be a flushing problem what makes the output appear out of sync... Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Steven Bethard wrote: > Fernando Perez wrote: >> Steven Bethard wrote: >> >> >>>I get the correct output, but if you run this yourself, you'll see that >>>the numbers 1 through 10 aren't printed in sync with the writes (i.e. >>>every half second); they're all printed at the end. Could someone >>>explain to me why this happens, and how (if possible) I can get the >>>numbers printed in sync with the appends to the list? >> >> >> This is just a shot in the dark, as I'm quite ignorant of threading details. >> But what happens if you try adding a sys.stdout.flush() call after the print >> statement in your custom update() method? It may just be a flushing problem >> what makes the output appear out of sync... > > Strangely enough, that causes PythonWin to hang... Why that would be > true, I have no idea... Mmh. I wouldn't be surprised if under pythonwin, sys.stdout is not the true python sys.stdout. Check the following: sys.stdout is sys.__stdout__ The answer is probably false. In that case, they may have implemented some incomplete object whose flush method is broken, or something similar. I can't confirm, as I don't have windows access, so this is just a guess. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Gnuplot.py and, _by far_, the weirdest thing I've ever seen on my computer
syd wrote: > I don't even know where to begin. This is just bizarre. I just picked > up the Gnuplot.py module (a light interface to gnuplot commands) and > was messing around with it today. > > I've got a tiny script, but it only works from the command line about > half the time! In the python interpreter, 100%. Ipython, 100%. I'm > not kidding. Nothing strange about it. When run standalone, the python interpreter quits and cleans up after itself, possibly deleting temp files before gnuplot gets a chance to use them. You can put a time.sleep(5) before exiting, or even safer, a full safety check: while 1: if os.path.isfile(your_plot_filename): break time.sleeep(1) Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Gnuplot.py and, _by far_, the weirdest thing I've ever seen on my computer
syd wrote: > Thanks for all the help, guys! > Fernando, that's a creative solution, I'll try it as well... > while 1: > if os.path.isfile(your_plot_filename): > break > time.sleep(1) More like a desperate brute force one, but it gets the job done :) You mentioned having ipython, so you can look in the Gnuplot2 module there, around line 630. You'll see the lengths ipython goes to to ensure that .eps files are properly created if you call plot() with a filename argument. That solution has a cutoff, it tries 20 times and eventually gives up if it still doesn't work. You may want to implement something similar, to avoid endlessly waiting for your plot in case there is a more serious problem preventing the file from being created at all. On a different note, you might want to check out matplotlib. I held out as a diehard gnuplot user for a long time, waiting for matplotlib to become production ready (I've been using gnuplot since 1991!). But mpl has really matured recently, and it offers a level of sophistication and features that gnuplot simply can't match. Give it a try, you may like it. I've moved my production code to it, and couldn't be happier. The gnuplot support will remain in ipython for those who like it, but I won't be adding further features to it (not that it has changed much in a while, as it's pretty solid). best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
Claudio Grondi wrote: > Considering what I found in the ipython mailing archives > and the fact, that after the fix with displaying colors on > bright backgrounds Gary had no time yet to get in touch > with me about the code I have sent him, I suppose, that > there will be no new releases addressing this problem > soon, right? Sorry to hear this; unfortunately readline/win32 is beyond my control, so there is not much I can offer on this front. You could try to write to Gary again, he might just have been swamped with other things at the time. Best, f -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython - problem with using US international keyboard input scheme on W2K
Michele Simionato wrote: > Me too :-( > I have already submitted my issues with the Italian keyboard > on WinXP with no great success. It works on Linux, but this > is not of a big help since my plan was to use ipython -p pysh on > Windows as a replacement of the shell :-( Bummer. I wonder, if the changes are minor and easy, perhaps you (or someone else) could offer Gary to take over maintenance of readline/win32? It sounds like he is perhaps too busy to keep up with the patches and improvements, so perhaps it's time for someone else to take over? That kind of library, while very useful, shouldn't require too much future maintenance once the remaining bugs are ironed out. After all, it's just meant to expose under Win32 the default GNU readline functionality, so there is not much 'new stuff' to do there, and once it works correctly (which I think it's currently very close to doing), not much else should be needed. Just a thouhgt... Best, f -- http://mail.python.org/mailman/listinfo/python-list
[ANN] IPython 0.6.13 is out.
Hi all, I'm glad to announce the release of IPython 0.6.13. IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist I've provided RPMs (for Python 2.3 and 2.4, built under Fedora Core 3), plus source downloads (.tar.gz). Fedora users should note that IPython is now officially part of the Extras repository, so they can get the update from there as well (though it may lag by a few days). There is also a native win32 installer which should work correctly for both Python 2.3 and 2.4. Debian, Fink and BSD packages for this version should be coming soon, as the respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice Liu) have the time to follow their packaging procedures. Many thanks to Enthought for their continued hosting support for IPython, and to all the users who contributed ideas, fixes and reports. In particular, thanks to Frederic Mantegazza for extensive discussions on embedding features which make ipython suitable for use in the kind of complex environments I had always wanted it to be used. WHAT is IPython? 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. Release notes - *** WARNING to pysh users *** A backwards-incompatible change has been made. 1. You must update your pysh profile (~/.ipython/ipythonrc-pysh): a) Add to it the line: import_all IPython.Extensions.InterpreterExec b) Delete the line execfile pysh.py 2. You must also delete from ~/.ipython/ the file pysh.py. *** END pysh warning. As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and the full ChangeLog at http://ipython.scipy.org/ChangeLog. The highlights of this release follow. * Improved variable capture from system commands. The %sc and %sx magics (and hence the !!syntax in Pysh) now capture to special objects which, while looking like strings/lists, provide automatic conversion between the various modes: In [12]: sc a=ls s*py In [13]: a # the returned object looks like a plain string Out[13]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py' In [14]: a.s # but you can see it as a string with pure whitespace Out[14]: 'sanner.py scopes.py splot.py strings.py' In [15]: a.l # as a list Out[15]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py'] In [16]: a.n # or as a string with newlines Out[16]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py' If you capture the result split as a list, the returned object exhibits the exact same interface with .s, .l and .n attributes: In [18]: sc -l b=ls s*py In [19]: b Out[19]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py'] In [20]: b.s Out[20]: 'sanner.py scopes.py splot.py strings.py' In [21]: b.l Out[21]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py'] In [22]: b.n Out[22]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py' Try the above and use a? and b? to see the full docstrings of these special objects, which can be extremely convenient when manipulating system commands output. * By default, IPython now binds the up/down arrow keys to search only in the history which matches your input so far. If you are an old user your ipythonrc file is NOT automatically updated, but you can get this effect by putting the following in it: readline_parse_and_bind "\e[A": history-search-backward readline_parse_and_bind "\e[B": history-search-forward * Many changes and improvements to make it easier to embed ipython into complex interactive environments. These changes were motivated by the needs of Frederic Mantegazza, and more details can be found on the -dev list archives and at this wiki page specially created for this discussion: http://www.scipy.org/wikis/featurerequests/IPython In particular, ipython now exposes the ability to set custom exception handlers, docstring extraction methods, custom tab-completion routines, and more. That wiki page also serves as documentation (with code examples) for some of these more complex features. IPython also now exposes its own input execution routine (the runlines() method). You can thus feed this method snippets of input (even multiline) with magic syntax and all other special extensions, which it will process as if they had been typed at the command line. * Multi-line specials are now active by default. This means that you can use special syntax, like !cmd, in python multi-line input. A silly example: In [26]: for i in range(3): : !ls $i : ls: 0: No such file or directory ls: 1:
[ANN] IPython 0.12 is out!
Hi all, on behalf of the IPython development team, I'm thrilled to announce, after an intense 4 1/2 months of work, the official release of IPython 0.12. This is a very important release for IPython, for several reasons. First and foremost, we have a major new feature, our interactive web-based notebook, that has been in our sights for a very long time. We tried to build one years ago (with WX) as a Google SoC project in 2005, had other prototypes later on, but things never quite worked. Finally the refactoring effort started two years ago, the communications architecture we built in 2010, and the advances of modern browsers, gave us all the necessary pieces. With this foundation in place, while part of the team worked on the 0.11 release, Brian Granger had already started quietly building the web notebook, which we demoed in early-alpha mode at the SciPy 2011 conference (http://www.archive.org/details/Wednesday-203-6- IpythonANewArchitectureForInteractiveAndParallel). By the EuroScipy conference in August we had merged Brian's amazing effort into our master branch, and after that multiple people (old and new) jumped in to make all kinds of improvements, leaving us today with something that is an excellent foundation. It's still the first release of the notebook, and as such we know it has a number of rough edges, but several of us have been using it as a daily research tool for the last few months. Do not hesitate to file issues for any problems you encounter with it, and we even have an 'open issue' for general discussion of ideas and features for the notebook at: https://github.com/ipython/ipython/issues/977. Furthermore, it is clear that our big refactoring work, combined with the amazing facilities at Github, are paying off. The 0.11 series was a major amount of work, with 511 issues closed over almost two years. But that pales in comparison to this cycle: in only 4 1/2 months we closed 515 issues, with 50% being Pull Requests. And very importantly, our list of contributors includes many new faces (see the credits section in our release notes for full details), which is the best thing that can happen to an open source project. We hope you will find the new features (the notebook isn't the only one! see below) compelling, and that many more will not only use IPython but will join the project; there's plenty to do and now there are tasks for many different skill sets (web, javascript, gui work, low-level networking, parallel machinery, console apps, etc). *Downloads* Download links and instructions are at: http://ipython.org/download.html And IPython is also on PyPI: http://pypi.python.org/pypi/ipython Those contain a built version of the HTML docs; if you want pure source downloads with no docs, those are available on github: Tarball: https://github.com/ipython/ipython/tarball/rel-0.12 Zipball: https://github.com/ipython/ipython/zipball/rel-0.12 * Features * Here is a quick listing of the major new features: - An interactive browser-based Notebook with rich media support - Two-process terminal console - Tabbed QtConsole - Full Python 3 compatibility - Standalone Kernel - PyPy support And many more... We closed over 500 tickets, merged over 200 pull requests, and more than 45 people contributed commits for the final release. Please see our release notes for the full details on everything about this release: http://ipython.org/ipython-doc/stable/whatsnew/version0.12.html * IPython tutorial at PyCon 2012 * Those of you attending (or planning on it) PyCon 2012 in Santa Clara, CA, may be interested in attending a hands-on tutorial we will be presenting on the many faces of IPython. See https://us.pycon.org/2012/schedule/ presentation/121/ for full details. * Errata * This was caught by Matthias Bussionnier's (one of our great new contributors) sharp eyes while I was writing these release notes: In the example notebook called display_protocol, the first cell starts with: from IPython.lib.pylabtools import print_figure which should instead be: from IPython.core.pylabtools import print_figure This has already been fixed on master, but since the final 0.12 files have been uploaded to github and PyPI, we'll let them be. As usual, if you find any other problem, please file a ticket --or even better, a pull request fixing it-- on our github issues site (https:// github.com/ipython/ipython/issues/). Many thanks to all who contributed! Fernando, on behalf of the IPython development team. http://ipython.org -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython 0.12 is out!
On Mon, 19 Dec 2011 20:00:03 -0800, alex23 wrote: > You read the installation instructions and did a 'python setup.py > install' as it states, yes? > > Installed that way for Python 2.7.2 under Win64 with no issues > whatsoever. Glad to hear that. Obviously since I announced it here I'll try to monitor this thread, but if the OP is still having problems with his installation, please don't hesitate to post a question on our user mailing list: http://mail.scipy.org/mailman/listinfo/ipython-user where other users and developers may be able to assist (I'll be on vacation shortly so I may not be able to reply here, hence the chances for effective help will be higher on the list). We had no reports of problems with Windows installations during the beta and RC, so we'd love to know what's causing any issues here to fix them for the next release. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
