pyrepl-0.6
Michael Hudson
> Fernando Pérez <fper...@yahoo.com> writes:
>
> > Michael Hudson wrote:
> >
> > [pyrepl]
> > > I have a new version sat on my irritatingly
> > > internet-disconnected home box which I'll release as soon as I
> > > remember to stick it on a floppy and bring it in to the
> > > department.
>
> Argh! Tomorrow, maybe.
And so it was (except it was a CD-R not a floopy and I forgot how to
drive mkisofs and had to fiddle file names when I got it here and ...)
Here's the new README:
This is pyrepl 0.6, a readline-a-like for Python, which seems to be
being released on 2001-11-27.
http://starship.python.net/crew/mwh/hacks/pyrepl.html
It requires python 2.1 (or newer) with the curses and termios modules
built, and features (in less than 3000 lines of code):
* sane multi-line editing
* history, with incremental search
* completion, including displaying of available options
* a fairly large subset of the readline emacs-mode keybindings
(adding more is mostly just a matter of typing)
* a liberal, Python-style, license
* a new python top-level
* no global variables, so you can run two or more independent readers
without having their histories interfering.
* generally speaking, a much more interactive experience than readline
(it's a bit like a cross between readline and emacs's mini-buffer)
There are probably still a few little bugs & misfeatures, but _I_ like
it, and use it as my python top-level most of the time.
To get a feel for it, type:
$ python pyrepl.py
One point that may confuse: because the arrow keys are used to move up
and down in the command currently being edited, you need to use ^P and
^N to move through the history.
Please direct comments to m...@python.net.
(If you've released open source software you'll know how frustrating
it is to see a couple of hundred downloads and only get a handful of
emails, so don't think I'll be irritated by the banality of your
comments!)
New since 0.5.1:
+ Rewrote the low level code to be (hopefully) more portable and
(certainly) clearer. Most of the code from 0.5.1 is still present,
but it's been moved around and refactored (and the names have
gotten more sensible).
+ The above process fixed a fair few bugs.
+ Implemented a few more emacs-mode bindings.
+ Nailed another couple of differences between my top-level and the
the default one, including playing nice with Tk.
+ Implemented a saner way of handling window resizes (a sane way of
handling signals! Call the Unix police!)
+ minimal testing on cygwin.
New since 0.5.0:
+ Realizing that it wasn't going to run under 2.0 after all, I ripped
out some of the 2.0 compatibility code.
Planned "at some point in the future":
- vi-mode
- GUI toolkit friendliness (done for tk)
- point-and-mark?
- undo support (0.5.1 had some undo support, but it didn't really
work, and 0.6.0 has none)
- user customization support (maybe even try to read $INPUTRC?)
- non-incremental history search? (prolly not worth it)
- a more incremental way of updating the screen.
An announcement will find it's way on to clpa & the usual Parnassus
thing will happen soon.
Enjoy!
M.
--
6. Symmetry is a complexity-reducing concept (co-routines include
subroutines); seek it everywhere.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Neil Schemenauer
> This is pyrepl 0.6, a readline-a-like for Python, which seems to be
> being released on 2001-11-27.
> * sane multi-line editing
This is cool. We have a little script that we use to interact with our
object database (ZODB). It's used to do ad hoc queries or maintenance
on the database. Usually we run it with "python -i". I installed the
files in the pyrepl distribution in site-packages and added a
__init__.py in order to make it a package. Next, I added the following
lines to the end of the script:
from pyrepl.python_reader import ReaderConsole
ReaderConsole(globals(), 0, None).interact()
It works great. Thanks Michael.
Neil
cmkl
during development I'm able to put several lines with
pyrepl.python_reader.ReaderConsole(vars(), 0, None).interact()
within the code, even inside functions!
All I need is 'import pyrepl.python_reader' at the beginnig of
the module. Now I can estimate the state of the programm interactivly
within the scope of the function - break pyrepl with CTRL<D> - proceed
with the script and take a break at the next line with pyrepl....
Some kind of debugging with hardcoded breakpoints or
'debbuging for dummies'. This is the thing I was looking for!
Carl
Neil Schemenauer <n...@python.ca> wrote in message news:<mailman.1006875515...@python.org>...
Michael Hudson
> Really cool,
>
> during development I'm able to put several lines with
>
> pyrepl.python_reader.ReaderConsole(vars(), 0, None).interact()
>
> within the code, even inside functions!
>
> All I need is 'import pyrepl.python_reader' at the beginnig of
> the module. Now I can estimate the state of the programm interactivly
> within the scope of the function - break pyrepl with CTRL<D> - proceed
> with the script and take a break at the next line with pyrepl....
>
> Some kind of debugging with hardcoded breakpoints or
> 'debbuging for dummies'. This is the thing I was looking for!
Heh, that is quite a neat idea. Certainly one that hadn't occurred to
me.
BTW, pyrepl can integrate itself somewhat into pdb (see pyrepl.py for
details), but it's not that thorough yet.
Cheers,
M.
--
same software, different verbosity settings (this one goes to
eleven) -- the effbot on the martellibot
Manoj Plakal
> cmkle...@gmx.de (cmkl) writes:
>
>>Really cool,
>>
>>during development I'm able to put several lines with
>>
>> pyrepl.python_reader.ReaderConsole(vars(), 0, None).interact()
>>
>>within the code, even inside functions!
>>
>>All I need is 'import pyrepl.python_reader' at the beginnig of
>>the module. Now I can estimate the state of the programm interactivly
>>within the scope of the function - break pyrepl with CTRL<D> - proceed
>>with the script and take a break at the next line with pyrepl....
>>
>>Some kind of debugging with hardcoded breakpoints or
>>'debbuging for dummies'. This is the thing I was looking for!
>>
>
> Heh, that is quite a neat idea. Certainly one that hadn't occurred to
> me.
>
> BTW, pyrepl can integrate itself somewhat into pdb (see pyrepl.py for
> details), but it's not that thorough yet.
Being able to have an interactive shell inside arbitrary
points in a program is cool for debugging. BTW, this
functionality is provided by the "Interactive Debug Probe"
in Wing IDE (wingide.com). You can stop the program
at any point and then launch a shell in the context of the
stack frame where you stopped.
Manoj
cmkl
Unfortunately WingIde is not available on HPUX. Does the
"Ability to debug applications running on a remote host" help there?
I guess not.
Manoj Plakal
> Manoj Plakal <pla...@yahoo.com> wrote in message news:<3C1531D9...@yahoo.com>...
>>
>> Being able to have an interactive shell inside arbitrary
>> points in a program is cool for debugging. BTW, this
>> functionality is provided by the "Interactive Debug Probe"
>> in Wing IDE (wingide.com). You can stop the program
>> at any point and then launch a shell in the context of the
>> stack frame where you stopped.
>>
>
> Unfortunately WingIde is not available on HPUX. Does the
> "Ability to debug applications running on a remote host" help there?
> I guess not.
The remote debugging might help. What you need to do
is copy a small stub program to the remote machine.
The stub talks to the IDE (running on the local machine,
which is either Linux or Windows) through XML-RPC.
The stub is in pure Python so you can run it
on HPUX if you have Python available there.
Though this is kinda slow and I wouldn't recommend
it if the HPUX box is your main development
machine. This was intended to debug stuff running
on a remote deployment machine.
Manoj