Re: Syntax error after upgrading to Python 2.4

[Fernando]

> I don't see the problem yet.  I certainly do not see anything that should
> have been affected by the upgrade (was it from 2.3 on XP also?)

Yes.

> After checking for nonprinting chars, I would shuffle the param-default
> lines to try to determine which is really at fault.  Good luck, or wait for
> a more helpful response.

I reinstalled version 2.3.5 and everything works fine now. It's
definately something related to the latest version.


This is one of the main resons I finally gave up using Python and
switched to Smalltalk. You can't concentrate on your work while someone
is permanently introducing changes to your tool.

Constantly adding new features to a language might be fun, but it
substantially increases the odds of adding bugs and misfeatures, such
as whatever was causing problems with my code or the 'perlish' syntax
for decorators.


Feeling much better now. :-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Fernando]

On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <[EMAIL PROTECTED]>
wrote:

>Looks like the BDFL is planning to take lambda, reduce, filter, and
>map out of Python in the next big rev of Python (so called Python
>3000):
>
>  

Basically, it says that it will get rid of the explicit map, filter
and reduce and substitute them by some syntactic sugar that uses them
implicitly. That's ok, and not a big deal.

It will also get rid of lambda, and it's not a great loss, since
python's version is so limited that it's almost useless. Besides,
given the syntactic sugar used to replace map, reduce and filter,
there's no real need for lambda in the most usual cases.

The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and forcing it into the static-typing mold. Python is
going the C++ way: piling feature upon feature, adding bells and
whistles while ignoring or damaging its core design. 

The new 'perlified' syntax for decorators, the new static type bonds
and the weird decision to kill lambda instead of fixing it are good
examples that show that Python is going the wrong way. What used to be
a cool language will soon be an interpreted C/C++ without any
redeeming value. A real pity...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming less Lisp-like

[Fernando]

On Tue, 15 Mar 2005 00:01:09 +0100, Torsten Bronger
<[EMAIL PROTECTED]> wrote:


>> The new 'perlified' syntax for decorators,
>
>Python lost its innocence here: The first really special character,
>disturbing the former syntax style.  Not important, but irritating.
>
>> the new static type bonds
>
>What is meant by that?

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp-likeness

[Fernando]

On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:

>Maybe You can answer my question what this simple LISP function does ?
>
>(defun addn (n)
> #'(lambda (x)
> (+ x n)))

The same as 
def addn(n):
def fn(x):
return n + x
return fn

>This is correct LISP-syntax if You bear in mind LISPs powerwull macro
>language...

defun is a macro but I don't think that's what you mean...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp-likeness

[Fernando]

On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:


>
>
>BTW, the fact that a closure refers to a variable itself rather to its
>current value can be used to check the true attitude of languages with
>respect to functional programming, by observing how they understand
>their basic loops :-)
>
>Python loses:
>
 closures = []
 for i in range(10):
>...def add(x):
>...   return x + i
>...closures.append(add)
>...
 closures[5](1000)
>1009
>
[snip]
>Scheme wins:
>
>> (let ((closures (make-vector 10)))
>(do ((i 0 (+ i 1)))
>((= i 10))
>(vector-set! closures i (lambda (x) (+ x i
>((vector-ref closures 5) 1000))
>1005
>
>and what is perhaps surprising, Perl wins:
>
>$ perl -e '
>   foreach my $i (0..9) {
>  push @closures, sub {$_[0] + $i}
>   }
>   print $closures[5](1000), "\n"'
>1005

Smalltalk 'loses' too:

closures := Array new: 10.
1 to: 10 do: [:i |
closures at: i put: [:x| x + i]].

(closures at: 5) value: 1000
returns 1011



>If you think it's unlikely that one would want to keep a closure
>referring to a loop control variable longer than the loop iteration
>which has created it, think about the loop body spawning a thread.

I'm still not convinced this is really useful, but Scheme's behavior
seems more intuitive.
-- 
http://mail.python.org/mailman/listinfo/python-list

are DLLs needed to run glade interfaces in python with Windows?

[Fernando]

Hi,
I've a .glade file with a little interface I made. I've managed to
load it from a python script, using pyGTK, but the only way it succeed
was copying into the same directory the "libxml2.dll" and
"libglade-2.0.0.dll" files.

I think you only need to install theese as packages in Linux, but I'm
using Windows and I'm wondering if this is a must using it, or if
there are ways much cleaner that simply start dropping DLLs inside the
directory...

Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Registering a python function in C

[fernando]

Could someone post an example on how to register a python function as
a callback in a C function? It expects a pointer to PyObject... how do
I expose that? Basically, the signature of the function is
foo(PyObject* obj), where obj is the callback function... It's not
exactly extending or embedding, I've looked at those examples but they
don't really show how to do this...

Thanks for the help!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Registering a python function in C

[fernando]

Thanks for the responses. To be more specific, this code is part of a
Maya plugin. The funcion MFnPlugin::registerUI takes a pointer to a
PyObject which is the function that will set up the UI for that
plugin. The code Matimus posted seems to me exactly like what I need
to do, except that maya gives me an error when I call
PyImport_ImportModule... I don't even have a chance to check the
return value, Maya simply gives up. I have checked that python is
initialized by the time I call this function, and the python path is
correct, I can load the module from the maya python interpreter. What
bugs me is that PyImport_ImportModule doesn't even return, it should
return 0 if something bad happened, right?

Here's my code:

if(Py_IsInitialized())
 cout << "python is already initialized" << endl;
if(!Py_IsInitialized()){
 cout << "had do initialize python" << endl;
 Py_Initialize();
}
PyObject* mod= PyImport_ImportModule("vzPyTest");
if(mod == 0){
 cout << "didn't load" << endl;
}
PyObject* func1 = PyObject_GetAttrString(mod, "vzPyTest.test1");
PyObject* func2 = PyObject_GetAttrString(mod, "vzPyTest.test2");
plugin.registerUI(func1, func2);


Thanks for the help!!!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Registering a python function in C

[fernando]

> Is Maya a different python build than what is contained at python.org?
> If so, I suggest you get your C program to work with the latest python
> build
> from python.org.  Then see if you can get it to work with the Maya
> version.

Ok, did that. If I write a normal C++ program and use the python
installed in my system, everything works ok and I can call the python
funtions. From within maya(where the C code is running as a plugin),
nothing happens. I tried removing my python installation so that only
the one that comes with maya is running, but then I have no python.h
or libs to compile against!! I found no help at the maya/python
newsgroup, is there anyone who has done this before???


Thanks for all the help!


-- 
http://mail.python.org/mailman/listinfo/python-list

Trouble with subprocess.Popen()

[Fernando]

Hi,

I'm having a very strange issue with subprocess.Popen.  I'm using it
to call several times an external exe and keep the output in a list.

Every time you call this external exe, it will return a different
string. However, if I call it several times using Popen, it will
always return the SAME string. =:-O  It looks like Popen is returning
always the same value from stdout, without recalling the exe.

This is my code:

def get_key():

from subprocess import Popen, PIPE

args = [C_KEY_MAKER, '/26', USER_NAME, ENCRYPTION_TEMPLATE, '0', ]
process = Popen(args, stdout=PIPE)
output = process.communicate()[0].strip()
return output


print get_key() # Returns a certain string
print get_key() # Should return another string, but returns the
same!
-

What on Earth am I doing wrong?!
--
http://mail.python.org/mailman/listinfo/python-list

[ANN] IPython 0.13 is officially out!

[Fernando Perez]

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.

[Fernando Perez]

otlib, teach courses and seminars
about scientific Python, and more recently help create the NumFOCUS
foundation project.  Despite the challenges that raising three
children in an expensive city like Chicago presented, he never once
wavered from his commitment to open source.  But unfortunately now he
is not here anymore to continue providing for their well-being, and I
hope that all those who have so far benefited from his generosity,
will thank this wonderful man who always gave far more than he
received.  Thanks to the rapid action of Travis Oliphant, the NumFOCUS
foundation is now acting as an escrow agent to accept donations that
will go into a fund to support the education and care of his wonderful
girls Rahel, Ava and Clara.

If you have benefited from John's many contributions, please say
thanks in the way that would matter most to him, by helping Miriam
continue the task of caring for and educating Rahel, Ava and Clara.
You will find all the information necessary to make a donation here:

http://numfocus.org/johnhunter

Remember that even a small donation helps! If all those who ever use
matplotlib give just a little bit, in the long run I am sure that we
can make a difference.

If you are a company that benefits in a serious way from matplotlib,
remember that John was a staunch advocate of keeping all scientific
Python projects under the BSD license so that commercial users could
benefit from them without worry.  Please say thanks to John in a way
commensurate with your resources (and check how much a yearly matlab
license would cost you in case you have any doubts about the value you
are getting...).

John's family is planning a private burial in Tennessee, but (most
likely in September) there will also be a memorial service in Chicago
that friends and members of the community can attend.  We don't have
the final scheduling details at this point, but I will post them once
we know.

I would like to again express my gratitude to Travis Oliphant for
moving quickly with the setup of the donation support, and to Eric
Jones (the founder of Enthought and another one of the central figures
in our community)  who immediately upon learning of John's plight
contributed resources to support the family with everyday logistics
while John was facing treatment as well as my travel to Chicago to
assist.  This kind of immediate urge to come to the help of others
that Eric and Travis displayed is a hallmark of our community.

Before closing, I want to take a moment to publicly thank the
incredible staff of the University of Chicago medical center.  The
last two weeks were an intense and brutal ordeal for John and his
loved ones, but the hospital staff offered a sometimes hard to
believe, unending supply of generosity, care and humanity in addition
to their technical competence.  The latter is something we expect from
a first-rate hospital at a top university, where the attending
physicians can be world-renowned specialists in their field.  But the
former is often forgotten in a world often ruled by a combination of
science and concerns about regulations and liability. Instead, we
found generous and tireless staff who did everything in their power to
ease the pain, always putting our well being ahead of any mindless
adherence to protocol, patiently tending to every need we had and
working far beyond their stated responsibilities to support us.  To
name only one person (and many others are equally deserving), I want
to thank Dr. Carla Moreira, chief surgical resident, who spent the
last few hours of John's life with us despite having just completed a
solid night shift of surgical work.  Instead of resting she came to
the ICU and worked to ensure that those last hours were as comfortable
as possible for John; her generous actions helped us through a very
difficult moment.

It is now time to close this already too long message...

John, thanks for everything you gave all of us, and for the privilege
of knowing you.

Fernando.

-- 
http://mail.python.org/mailman/listinfo/python-list

how to use property?

[Fernando Jiménez]

Hi guys!

I'm noob in python and I would know how to correctly use the property. I
have read some things about it but I do not quite understand.

I found this:

class C(object):
def __init__(self):
self._x = None

@property
def x(self):
"""I'm the 'x' property."""
return self._x

@x.setter
def x(self, value):
self._x = value

@x.deleter
def x(self):
del self._x

But I think it's a bad habit to use _ to change the visibility of the
attributes as in JAVA.

How to correctly use the property?
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] IPython 0.11 is officially out

[Fernando Perez]

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 ;)

[Fernando Perez]

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)

[Fernando Perez]

> 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?

[Fernando Perez]

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?

[Fernando Perez]

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?)

[Fernando Perez]

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?

[Fernando Perez]

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: Zope vs Php

[Fernando Lujan]

Jorge Godoy wrote:

>Mike Meyer <[EMAIL PROTECTED]> writes:
>  
>
>>That said, I have to confess that lately I've been using Cheetah
>>templates, because the syntax for inserting values is simpler, and the
>>way Cheetah templates work naturally in the Python inheritance
>>hierarchy.
>>
In this article you will have a great overview about Zope and Zope 3.

http://www.zopemag.com/Issue010/Section_Articles/article_WhyZope3.html

Fernando Lujan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Readline configuration

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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.

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

[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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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]

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]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

python SMTP server

[Fernando M.]

Hi,
i made a test with smtplib module a few days ago, for sending mails,
and i was wondering if there's another module for running an SMTP
server, so i could make a standalone script for sending mails without
using an external SMTP server.
I've been searching but i'm not sure if there are modules for it, or
anything.
Which ones are my options?

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dabo in 30 seconds?

[Fernando Perez]

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?

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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 ?

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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()

[Fernando Perez]

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()

[Fernando Perez]

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

[Fernando Perez]

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.

[Fernando Perez]

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.

[Fernando Perez]

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

[Fernando Perez]

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

[Fernando Perez]

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.

[Fernando Perez]

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

[Fernando Perez]

[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

[Fernando Perez]

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 ?)

[Fernando Perez]

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

[Fernando Perez]

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]

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__?

[Fernando Perez]

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]

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__?

[Fernando Perez]

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__?

[Fernando Perez]

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__?

[Fernando Perez]

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__?

[Fernando Perez]

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.

[Fernando Perez]

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?)

[Fernando Perez]

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

[Fernando Perez]

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?)

[Fernando Perez]

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?

[Fernando Perez]

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?

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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]

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

[Fernando Perez]

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?

[Fernando Perez]

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

[Fernando Perez]

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