[Python-Dev] a quit that actually quits
Nick Coghlan
ncoghlan at gmail.com
Wed Dec 28 18:28:22 CET 2005
[Alex]
>> Just brainstorming, but -- maybe this means we should generalize the idea? I.e., allow other cases in which "just
>> mentioning X" means "call function Y [with the following arguments]", at least at the interactive prompt if not more
>> generally. If /F's idea gets
>> implemented by binding to names 'exit' and 'quit' the result of some factory-call with "function to be called" set to
>> sys.exit and
>> "arguments for it" set to () [[as opposed to specialcasing checks of last commandline for equality to 'exit' &c]]
>
[Walter]
> We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? sys.inputhook gets passed each line entered and may
> return True if it has processed the line inself and False if normal handling of the input should be done.
> This allows special treatment of "quit", "exit", "help" and it might make implementing alternative shells for Python easier
> (without having to subclass code.InteractiveConsole).
[Alex]
>> then the
>> implementation of the generalization would be no harder. I do find myself in
>> sessions in which I want to perform some action repeatedly, and
>> currently the least typing is 4 characters (x()<enter>) while this would reduce it to two
Hmm. . .
def default_inputhook(statement):
try:
aliased = sys.aliases[statement]
except KeyError:
return False
else:
aliased()
return True
sys.aliases = dict(exit=sys.exit, quit=sys.exit)
sys.inputhook = default_inputhook
I think Walter's idea may have merit (although I believe the input hook should
be passed whole statements, rather than individual lines).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
More information about the Python-Dev
mailing list