[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