ANNOUNCE: pyrepl 0.5.0 (was: ANNOUNCE: Readline Alternative 1.2)

[Michael Hudson]

"Bruce Edge" <bedge at troikanetworks.com> writes:

> > 
> > Mine's at:
> > 
> > http://starship.python.net/crew/mwh/hacks/pyrepl.html
> > 
> > Cheers,
> > M.
> 
> Hi,
> Great news, I've had issues with readline for a while.

Thanks for the interest!

> Got a few questions. If the answer is "go read the code", that's
> fine too, but I have to ask anyways.

Well, reading the code isn't especially easy at the moment.  It's
evolved gradually over the course of some months (even though I've
thrown everything out and started again at least twice), and this
doesn't make for easy to read code.

> First, there's a typo in completer.py:
> 
>     def complete(self, text):
>         if "." in text:
>             ruern self.attr_matches(text) <---
>         else:
>             return self.global_matches(text)

Eek!  At least that's easy to fix.

> Second, one of the issues I've had with readline is how to re-init
> it to clear out old history. When I use pdb, I want to change my
> history file name, and then reload my old history when I exit pdb,
> and none of the existing history commands apply in pdb vs. python
> shell.  Can you do this with pyrepl?

For sure!  You'd just use different readers for pdb and the Python
top-level.  This isn't completely trivial as pdb.Pdb is written to use
cmd.Cmd so you'd need to rewrite a bit (hmm, I wonder if one could
write a class that you could inherit from a Cmd-using class with to
get a pyrepl-using class...).

In effect, this works already though: the top-level of pyrepl uses its
history and pdb will use readline's.

> Third, Key binding, what functions can you bind keys to?

Whatever is in the reader's classdict attribute.  What's in there
depends on the make_classdict function of the reader you've
instantiated...  there are lots and lots of examples of commands in
commands.py, and some more in historical_reader.py &
completing_reader.py.

> Lastly, Do you have any docs on the API, or had you intended it to
> be an interactive python goodie only?

Maybe.  I wouldn't regard the API as fixed just yet; as I hinted
above, I think bits of it are somewhat insane.  Though attempting to
document it might well help me spot which bits.

Also, I need feddback so I can spot places where the API is a bit
broken or insufficiently general (I have a few of these already).

Thanks for the comments,
M.

-- 
  This is not to say C++ = bad, Lisp = good.  It's to say
  C++ = bad irrespective of everything else.
                                       -- Alain Picard, comp.lang.lisp