[Python-Dev] a quit that actually quits
Walter Dörwald
walter at livinglogic.de
Wed Dec 28 18:04:55 CET 2005
Alex Martelli wrote:
> On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
>
>> skip at pobox.com writes:
>>
>>> Fredrik> a quit/exit command that actually quits, instead of
>>> printing a
>>> Fredrik> "you didn't say please!" message.
>>>
>>> I like Fredrik's idea more and more.
>>
>> The thing that bothers me about it is that the standard way you tell python to do something is "call a function" -- to me, a
>> special case for exiting the interpreter seems out of proportion.
>
> 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]]
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).
> 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
What's wrong with <cursor up>, <return>?
> (iPython does allow such handy
> shortcuts, but I'm often using plain interactive interpreters).
>
> If this generalization means a complicated implementation, by all means let's scrap it, but if implementation is roughly as
> easy, it may be worth considering to avoid making a too-special "special
> case" (or maybe not, but brainstorming means never having to say you're sorry;-).
Bye,
Walter Dörwald
More information about the Python-Dev
mailing list