skip@pobox.com wrote:

Fredrik> whaddya think?

We're going to wind up with the same problem that spawned the atexit module: multiple code sources wanting to fiddle with sys.excepthook step on one another's toes.

in this case, I'm not sure it matters that much. if you add your own except- hook, you take responsibility. (it would be nice if it was possible to detect "interactive mode" when the site code runs, though. does anyone know if that's possible ?) </F>

On 27-dec-2005, at 14:55, Christopher Armstrong wrote:

On 12/28/05, Reinhold Birkenfeld wrote:

...

Fredrik Lundh wrote:

...

sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread.

this silly little patch changes the behaviour of the interpreter so that "quit" and "exit" actually exits the interpreter. it does this by installing a custom excepthook that looks for NameErrors at the top level, in interactive mode only.

What is wrong with something like this:

...

...

...

class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter()

It could optionally check for top level too, of course.

Not sure if this is what you mean by "check for top level too", but the obvious problem is that calling vars(__builtins__) (or similar) will cause your interpreter to exit. :)

Why must quit and exit be so special in the first place? They could be plain functions, or even something like:: class _QuitOrExit: def __init__(self, name): self.name = name def __repr__(self): return "Use %(name)s() to exit."%(self.__dict__) def __call__(self): raise SystemExit quit = _QuitOrExit("quit") exit = _QuitOrExit("exit") Ronald

On 27-dec-2005, at 16:39, Fredrik Lundh wrote:

Ronald Oussoren wrote:

...

Why must quit and exit be so special in the first place? They could be plain functions, or even something like::

class _QuitOrExit: def __init__(self, name): self.name = name

def __repr__(self): return "Use %(name)s() to exit."%(self.__dict__)

def __call__(self): raise SystemExit

quit = _QuitOrExit("quit") exit = _QuitOrExit("exit")

but now we're back to today's situation:

...

...

...

quit 'Use Ctrl-Z plus Return to exit.'

which violates the basic "if you know what I mean, why the /!"&/&!//%¤ don't you do what I say" usability rule.

I'd prefer 'def quit(): raise SystemExit', the class above just adds a message for someone that accidently got stuck in a python shell. I don't like the idea of making quit or exit special enough to cause side effects without parentheses, no other function does that. Anyone that knows how to program in Python should be able to guess that you have to use 'quit()' instead of 'quit'. BTW. I do agree that the current situation is stupid. Ronald

</F>

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com

Martin> So if they do >>> quit Martin> they are just as confused as if they got a name error. Probably more so... <wink> Skip

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ka-Ping Yee wrote:

[...] (b) If more handholding seems like a good idea, then:

class ExitHatch: def __call__(self): sys.exit() def __repr__(self): return '' __builtins__.exit = __builtins__.quit = ExitHatch()

That looks like a good compromise to me. - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsdPWdIO4ozGCH14RAsTyAKCW5mwCJ/cN+UbKICufXwmDIX9/tgCfQLJa LaEL4a4pV7Jhnh3ry/b+CrU= =/FQl -----END PGP SIGNATURE-----

Brett Cannon wrote:

And Tim had a good point about PDAs and such; how are they supposed to exit? What if someone picked up Python for their Nokia S60 phone and tried to exit from the interpreter? Unless Nokia has tweaked something I don't know how they would know to exit without knowing about sys.exit() or raising SystemExit since I wouldn't know how to do the equivalent Ctrl-D on a cell phone.

The version of Python on my phone (2.2.2) doesn't recognize "quit" or "exit," but there is a soft key conveniently labeled "Exit" which drops out of the interactive console.

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. Without my Unix bifocals it wouldn't occur to me that Ctrl-D is the way to exit. Knowing Ctrl-Z is EOF on Windows, it wouldn't occur to me that I'd also have to hit Return. Without my Python shades I'd never guess to exit via "raise SystemExit". While the raise command is "one true way", it certainly won't occur to newbies. I have no idea how I'd exit from Pippy or from the interpreter prompt on a Nokia phone without it. In short, I think it makes a lot of sense to support a bare "exit" and/or "quit" as a completely intuitive platform-independent newbie-friendly way to exit the interpreter. Skip

skip@pobox.com wrote:

In short, I think it makes a lot of sense to support a bare "exit" and/or "quit" as a completely intuitive platform-independent newbie-friendly way to exit the interpreter.

I can readily agree to this part of Fredrik's proposal. What slightly bothers me is the hackish nature of the proposed implementation. Regards, Martin

Fredrik Lundh wrote:

any suggestions on how to improve this ?

Introducing sys.commandline is fine; overriding sys.excepthook still worrisome. What's wrong with triggering this in some __repr__ implementation? If an excepthook must be installed, why couldn't the previous excepthook be preserved, and called in case the exception is not what you are looking for? Of course, even if this excepthook behaves friendly, some other package might overwrite excepthook without preserving yours, in which case people would "sometimes" get a NameError when they try to exit. Regards, Martin

Fredrik Lundh wrote:

this is done in site.py, before sitecustomize is loaded. I'm not sure how anyone else would be able to squeeze in an excepthook at this point, even if they wanted...

I see. Still, I think the Python code should give a good example. There *is* an excepthook installed at that point, anyway, so we should use it. Otherwise, I think the approach is fine. Regards, Martin

skip@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. In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of "if input.rstrip() == 'exit': sys.exit()" in the implementation of the interactive interpreter? Cheers, mwh -- My first thought was someone should offer Mr. Bush elocution lessons. But he'd probably say he knew how to work them chairs already. -- Internet Oracularity #1294-01

Michael Hudson wrote:

In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of "if input.rstrip() == 'exit': sys.exit()" in the implementation of the interactive interpreter?

that would turn exit and quit into reserved keywords. </F>

Michael Hudson wrote:

...

that would turn exit and quit into reserved keywords.

In what sense? Not in the sense of "things in single quotes in Grammar"...

no, but in the sense of "names that can no longer be used in code" >>> def exit(): ... print "bye" >>> # what is it? >>> exit $ oops! the whole nameerror thing is there to avoid problems if you create your own exit variables/functions/classes/modules. </F>

...

...

...

...

"Martin" == Martin v Löwis writes:

Martin> That would assume that the user knows that exit is a Martin> function: apparently, people expect it to be a statement Martin> (like print), Oh, the irony of that analogy!<wink> Martin> or they are entirely unaware of the distinctions between Martin> statements, expressions, and functions. Then there's little point to giving them access to the interpreter! Of course, Martin also mentioned "students". Python is not the only language in the world; we all know that, even if most of us much prefer programming in Python to any other environment. If you're teaching, why not use this as an opportunity to deliver a brief lecture on why Python does things differently, and why one should understand a _formal_ language in its own terms, not in terms of what you (the user/programmer) want it to be for momentary convenience? My feeling is that the current behavior of "exit" and "quit" is not "you didn't say please" but "excuse me, I don't speak BASIC; would you say that in Python or signal that the conversation is over (ie, EOF)?" For me, that's part of the Zen of Python. Probably I'm just missing something given the amount of support this idea is getting, from really respectable sources, too, but it just seems wrong to change this. What's wrong with having a distinctive personality? I suppose the current value of those variables sounds a bit rude. Why not fix the discourtesy, rather than what's not broken (IMHO)? exit = """\ The Python interpreter simply interprets a Python program. It provides no special interactive commands. The line editor is a thin front-end to the standard input stream. To exit your program, use one of the functions or exceptions provided for this purpose, or simply end the file (interactively this is signaled by Ctrl-D). This public service message brought to you by the global variable 'exit'.""" -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Alex Martelli wrote:

On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:

...

skip@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

On 12/28/05, Walter Dörwald wrote: ...

We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?

Sure, particularly with Nick's suggestion for a default input hook it would be fine.

...

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>?

The fact that there is no upper bound to the number of cursor-up keystrokes needed here -- by "perform some action repeatedly" I don't mean "half a dozen times right after each other with nothing in-between" (sorry for the ambiguous phrasing), but "numerous times, repeatedly in the course of an interactive interpreter session". Alex

Walter Dörwald wrote:

Alex Martelli wrote:

...

On 12/28/05, Walter Dörwald wrote: ...

...

We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook?

Sure, particularly with Nick's suggestion for a default input hook it would be fine.

I'd like the inputhook to be able to define the prompt. I'm not sure how this could be accomplished.

Another API would be that the inputhook returns what line or command should be executed instead, e.g.

def default_inputhook(statement): if statement.endswith("?"): return "help(%s)" % statement[:-1] etc.

And you're on your way to re-writing ipython: In [1]: x='hello' In [2]: x? Type: str Base Class: String Form: hello Namespace: Interactive Length: 5 Docstring: str(object) -> string Return a nice string representation of the object. If the argument is a string, the return value is the same object. I also started it with "let's add a cool hack to sys.ps1 and sys.displayhook in 10 minutes". Now we're at 18000 lines of python, a 70 page manual, and growing suport for remote distributed interactive computing, a new scientific computing GUI, and more :) If you like this kind of thing, by all means join in: I can use all the helping hands I can get. Cheers, f

Fredrik Lundh wrote:

Fernando Perez wrote:

...

In [1]: x='hello'

In [2]: x? /.../ Docstring: str(object) -> string

Return a nice string representation of the object. If the argument is a string, the return value is the same object.

I'm not sure what I find more confusing: a help system that claims that the variable x returns a nice string representation of an object, or that there's no help to be found for "hello".

Then, complain about docstrings: Python 2.3.4 (#1, Feb 2 2005, 12:11:53) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

x='hello' print x.__doc__ str(object) -> string

Return a nice string representation of the object. If the argument is a string, the return value is the same object. ==== In ipython, '?' does the best it can to collect information about an object, making heavy use of python's introspection capabilities. It provides class and constructor docstrings, function call signatures (built from the function code object), and more. Using ?? gives even more details, including syntax-highlighted source when available. For example: In [5]: pydoc.ErrorDuringImport?? Type: classobj String Form: pydoc.ErrorDuringImport Namespace: Interactive File: /usr/lib/python2.3/pydoc.py Source: class ErrorDuringImport(Exception): """Errors that occurred while trying to import something to document it.""" def __init__(self, filename, (exc, value, tb)): self.filename = filename self.exc = exc self.value = value self.tb = tb def __str__(self): exc = self.exc if type(exc) is types.ClassType: exc = exc.__name__ return 'problem in %s - %s: %s' % (self.filename, exc, self.value) Constructor information: Definition: pydoc.ErrorDuringImport(self, filename, (exc, value, tb)) I'm sorry it can't provide the information you'd like to see. It is still found to be useful by many people, including myself. You are welcome to use it, and patches to improve it will be well received. Best, f

Fredrik Lundh wrote:

Walter Dörwald wrote:

...

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" /.../

so how would such a hook deal with the

>>> def exit(): ... pass >>> exit

case ?

In the inputhook one would have to check for "exit" being defined at interpreter level. Reinhold -- Mail address is perfectly valid!

Here's yet a different take on this: why not simply change the startup message? Whether we choose "quit" or "exit", someone will get it wrong unless there's an alias. Changing the message is free. Currently we have Type "help", "copyright", "credits" or "license" for more information. Let's add another line that says Type "quit()" to exit Defining it as "def quit(): raise SystemExit" should be fine. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger." --Roy Smith

On Wed, Dec 28, 2005, Brett Cannon wrote:

On 12/28/05, Aahz wrote:

...

Here's yet a different take on this: why not simply change the startup message? Whether we choose "quit" or "exit", someone will get it wrong unless there's an alias. Changing the message is free. Currently we have

Type "help", "copyright", "credits" or "license" for more information.

Let's add another line that says

Type "quit()" to exit

Defining it as "def quit(): raise SystemExit" should be fine.

Just because people don't read unless it it thrown in their face. =) But that is still nice and simple and won't hurt. I would still suggest using a class so that the repr can give a useful message, though.

That's fine. I think the primary use case for this is someone who accidentally stumbles into the Python interpreter, in which case that message will be a life-saver. Anybody who is formally attempting to use the interpreter probably has ready access to docs that explain how to use it. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger." --Roy Smith

Scott David Daniels wrote:

Or, perhaps: class _Quitter(str): def __call__(self): raise SystemExit quit = _Quitter('The quit command. Type "quit()" to exit') exit = _Quitter('The exit command. Type "exit()" to exit')

FWIW, I like this kind of solution best. Something magical would be a mistake. I don't like the status quo because there is no cross-plaform way to indicate EOF (or more pedantically "push current line"). Maybe we can make everyone happy by making the 'quit' and 'exit' objects callable and changing the message to something like: Use quit() or Ctrl-D (i.e. EOF) to exit. Cheers, Neil

Nick Coghlan wrote:

As Fernando pointed out, anything else means we'd be well on our way to re-inventing IPython (although I'd be interested to know if sys.inputhook would have made IPython easier to write).

[sorry if this drifts off-topic for python-dev. I'll try to provide useful info on interactive computing in python here, and will gladly answer further detailed discussion about ipython on the ipython-dev/user lists ] In my case, I don't think it would have made that much of a difference in the end, though initially it might have been tempting to use it. IPython started as my private collection of sys.ps{1,2} + sys.displayhook hacks in $PYTHONSTARTUP. I then discovered LazyPython, which had a great sys.excepthook, and IPP, which was a full-blown derivative of code.InteractiveConsole. I decided to join all three projects, and thus was ipython born. Given that IPP was the 'architecture', from the moment we had what is still today's ipython, it was based on code.InteractiveConsole, and at that point I doubt that having sys.inputhook would have mattered. Incidentally, just two days ago I removed the last connection to code.py: at this point I had overridden so many methods, that there was no point in keeping the inheritance relationship. All I had to do was copy _two_ remaining methods, and the main ipython class became standalone (this frees me for ongoing redesign work, so it was worth doing it). So in summary, while sys.inputhook would make it easy to do _lightweight_ interactive customizations, if you really want a more sophisticated and featureful system, it probably won't matter. Note that this is not an argument against sys.inputhook: exposing customizability here may indeed be useful. This will allow people to write, with minimal effort, systems which pre-process special syntaxes and ride on top of the python engine. IPython exposes the exact same thing as a customizable hook (called prefilter), and people have made some excellent use of this capability. The most notable one is SAGE: http://modular.ucsd.edu/sage a system for interactive mathematical computing (NSF funded). If anyone is in the San Diego area, the first SAGE meeting is in February: http://modular.ucsd.edu/sage/days1/ and I'll be giving a talk there about ipython, including some of its design and my plans for a more ambitious system for interactive computing (including distributed computing) based on Python. The prototypes of what we've done so far are briefly described here (the first was funded by Google as a summer of code project): http://ipython.scipy.org/misc/ipython-notebooks-scipy05.pdf http://ipython.scipy.org/misc/scipy05-parallel.pdf I hope this is of some use and interest. Regards, f

Alex Martelli wrote:

On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:

...

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]] 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 (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;-).

Allow me to add a few comments, here: as the ipython author, I happen to have thought an awful lot about all these issues. First, your suggestion of incorporating 'autocalling' ( the automatic 'foo a' -> 'foo(a)' transformation) into the core python interpreter may not be a very good idea. The code that does this is precisely the most brittle, delicate part of ipython, a little regexp/eval/introspection dance that tries really, really hard to understand whether 'foo' is a string that will point to a callable once evaluated, but without eating generators, causing side effects, or anything else. I know it sounds silly, and perhaps it's just my limitations, but it has taken several years to flesh out all the corner cases where this code could fail (and in the past, a few really surprising failure cases have been found). In ipython, this functionality can still be turned off (via %autocall) at any time, in case it is not working correctly. You are welcome to look at the code, it's the _prefilter method here: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/iplib.p... So while I think that this is extremely useful in a third-party library like ipython, it's probably a little too delicate for the core, official interpreter where reliability is so absolutely critical. In fact, my own standard is that I trust the CPython prompt as a test of 'doing the right thing', so I like that it remains simple and solid. Now, on to the wider discussion started by the quit/exit debate: the problem is that we are here trying to make some particular words 'interactive commands' in a language that doesn't have such a notion to begin with. The tension of how best to implement it, the various low-level tricks proposed, etc, stems (I think) from this underlying fact. In IPyhton, I've convinced myself that this is a problem whose proper solution requires an orthogonal command subsystem, the 'magics' (credit where credit is due: the magic system was already in IPP, Janko Hauser's library which was one of ipython's three original components; Janko understood the issue early on and got it right). This creates a separate namespace, controlled by a disambiguation character (the % prefix in ipython), and therefore allows you to cleanly offer the kind of behavior and semantics which are more convenient for command-line use (whitespace argument separation, --dashed-options) without colliding with the underlying language. By having the 'magic' command system be separate, it is also trivially extensible by the users (see http://ipython.scipy.org/doc/manual/node6.html#SECTION00062000000000000000 for details). This means that instead of going into a never-ending rabbit-chase of special cases, you now have a well-defined API (IPython's is primitive but it works, and we're cleaning it up as part of a major rework) where users can add arbitrary command functionality which remains separate from the language itself. The main point here is, I think, that any good interactive environment for a programming language requires at least TWO separate kinds of syntax: 1. the language itself, perhaps with aids to economize typing at the command line (ipython offers many: auto-calling, auto-quoting, readline tricks, input history as a Python list, output caching, macros, and more). 2. a set of control commands, meant to manipulate the environment itself. These can obviously be implemented in the underlying language, but there should be a way to keep them in a separate namespace (so they don't collide with user variables and can be always called). I'll be glad to discuss this further, either here or on the ipython lists where this is probably more appropriate. But I wanted to give the python-devs some perspective on this, from having spent a lot of time dealing directly with the isues. Finally, I'd like to provide a bit of a plea: I hope that python itself doesn't end up polluting the core sys namespace with too many special things for interactive use. I think that a proper interactive console is best implemented as a separate extension (ipython, pycrust, idle, etc). Putting all these special-case things into sys ends up propagating everywhere, and potentially colliding with such systems (ipython has its own sys.excepthook, for example). Please keep the core (sys is very much part of the core) as clean as possible, and let the interactive shell writers add the functionality outside. Best, f ps - thanks to this thread, I've changed ipython from having the old-style quit/exit strings with the message, to being magics which exit. It had always had %Quit/%Exit for unconditional exit, but now (SVN) it also has %quit/%exit which honor the confirm_exit rc setting.

On Wed, 28 Dec 2005, Fredrik Lundh wrote:

...

It sounds to me like what is being proposed amounts to essentially "promote sys.exit to a builtin". no, what's being proposed is what the subject says: a quit/exit command

Ka-Ping Yee wrote that actually quits, instead of printing a "you didn't say please!" message.

Okay, that would be fine. It's just that the solutions so far that work without parentheses are a bit too magical for me. Fredrik's NameError-based proposal (exit when there's an exception with no tb_next that says "name 'exit' is not defined") causes the interpreter to quit when you enter any expression involving 'exit'. print exit # seems surprising [3, 4, 5, exit] # seems surprising 'a' in 'xyz' or exit # desirable or undesirable? del exit # actually happened to me x = exit # seems surprising Reinhold's proposal (exit when sys._getframe(1).f_code.co_names is ("exit",)) causes the interpreter to quit whenever any function attempts to print out or represent 'exit', as long as it doesn't mention any other variables. print exit # seems surprising [3, 4, 5, exit] # seems surprising 'a' in 'xyz' or exit # desirable or undesirable? def foo(): print exit foo() # seems surprising I'd be happy with having Python exit when the user types just plain 'exit' without parentheses, but only in that case, not others. However, i'm starting to think that may be impossible to implement. I can't think of any way to make 'print exit' not exit, for example. ("'exit'" is a shorthand for "'exit' or 'quit'" above.) -- ?!ng

Ka-Ping Yee wrote:

I'd be happy with having Python exit when the user types just plain 'exit' without parentheses, but only in that case, not others. However, i'm starting to think that may be impossible to implement. I can't think of any way to make 'print exit' not exit, for example.

OK, here's one: def quithook(obj, _exit=__builtins__.exit, _displayhook=sys.displayhook): if obj is _exit: raise SystemExit _displayhook(obj) sys.displayhook = quithook It does, however, fall into the whole issue of chaining that Skip brought up earlier. -- Jeremy Kloth Fourthought, Inc. http://fourthought.com/ http://4suite.org/

Martin v. Löwis wrote:

The thing is there primarily for people who *don't* know how to program in Python. If they knew, they knew how to get out of it; they wouldn't type "quit()" but simply Ctrl-D.

Except that on Windows, it's Ctrl-Z. This can be quite confusing when you regularly use Python on both Windows and Unix, and use the wrong key combination. Ctrl-D on Windows does not have the desired result, and Ctrl-Z on Unix suspends the process. (And if you use a GUI version, they often have their own rules... on IDLE for Windows, Ctrl-D works but Ctrl-Z doesn't; on PyCrust, neither one works.) Granted, it's not a big problem, but it *is* annoying. IMHO, it would be more useful if you could just type 'exit' or 'quit' (like in many other interpreters) and be done with it, rather than having to remember the correct key combination. (A key combination which has nothing to do with the Python language per se.) -- Hans Nowak http://zephyrfalcon.org/

Martin v. Löwis wrote:

If you want to type something consistently across platforms, you can currently do

...

...

...

raise SystemExit

I'm not sure what to say to that. Do you really want to type "raise SystemExit" every time you want to exit the interpreter? (Your answer would probably be something like "No -- that's why I use Ctrl-D". But that wouldn't really get us anywhere, would it?) My point is that there is currently no acceptable, universal way to exit the interpreter. Again, it's not that big of a deal... but it seems silly that something apparently trivial like that cannot be done right. -- Hans Nowak http://zephyrfalcon.org/

Hans Nowak wrote:

My point is that there is currently no acceptable, universal way to exit the interpreter. Again, it's not that big of a deal... but it seems silly that something apparently trivial like that cannot be done right.

it's the usual problem: getting enough developers to agree that this really is a problem is a lot more work than implementing it... oh, well. looks like SF is back up again. I'll post the patch over there when I find the time... </F>

Adal Chiriliuc wrote:

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

...

...

...

exit 'Use Ctrl-Z plus Return to exit.'

I've just tried Ctrl+Z (plus Return) and some variations on Win XP and it doesn't work! Ctrl+D does.

WinXP or WinXP+Cygwin ? here's what I get:

python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

...

...

^Z

python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

...

...

^D File "<stdin>", line 1 ? ^ SyntaxError: invalid syntax

</F>

Adal Chiriliuc wrote:

I have a solution proposal (I have no idea if it's feasible): why not intercept "exit" and "quit" in the interpreter command line parser? A simple regexp should do. Is the interactive interpreter implemented in Python or on the C side?

In short: it's not feasible. Please don't propose such things on python-dev without an implementation strategy in mind. Regards, Martin

On 12/27/05, Fredrik Lundh wrote:

but now we're back to today's situation:

>>> quit 'Use Ctrl-Z plus Return to exit.'

which violates the basic "if you know what I mean, why the /!"&/&!//%¤ don't you do what I say" usability rule.

What nonsense. Every Python programmer knows that the right way to exit Python is to enter a platform EOF. The quit and exit variables are compromises for non-programmers who have accidentally entered Python and who don't know how to get out of it (this is usually the same category of people who don't know how or don't dare to kill a program using heavy artillery). Rather than improving upon the quit/exit functionality a la /F's patch I'd get rid of the compromise. Now, for Py3K we could try to come up with a more intelligent interactive mode. Probably not implemented in C. Perhaps using ideas from ipython (which I've personally never used). We might provide a quit or exit command using a more sophisticated mechanism. But there are always costs (e.g. the violation of the primciple that typing a name shows its repr()). In the mean time I'm a strong believer in "it ain't broke so don't fix it" here. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

(for those who follow non-python forums

make that "those who don't follow" </F>

skip@pobox.com wrote:

Fredrik> make that "those who don't follow"

What might some of those non-python forums be?

assorted corners of the blogosphere, mostly. no time to dig up any explicit references, since I'm preparing for a 650 km trip through a major snowstorm, but searching backwards from bruce eckel's recent "The departure of the hyper-enthusiasts" might help you find some: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 </F>

Steve Holden wrote:

Except that if you have iPython installed on Windows you *don't* enter the platform EOF any more, you enter CTRL/D (which threw me for a while).

To be fair, that's due to the win32 readline library used by ipython, which modifies console handling. IPython itself doesn't do anything to the EOF conventions, it's pure python code with no direct access to the console. Cheers, f

On Wed, Dec 28, 2005, Guido van Rossum wrote:

In the mean time I'm a strong believer in "it ain't broke so don't fix it" here.

Does that also include my suggestion about improving the startup message? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger." --Roy Smith

Guido van Rossum wrote:

Regarding the meme floating about the arrogance of Pythoneers: bloggers (pretty much by definition) are actually the most arrogant species; don't confuse "bloggers say" with "most people think".

Sure, but I'm not only talking about the mindless ranters here; it's also people that back their opinions with at least a few examples -- including exit (and its "it's good for you that you have to learn more than you want at a time when you're not interested" defenders), replies to "what's wrong with Python's floating point type" along the lines of "that you don't under- stand how floating point works", and so on. (fwiw, this meme has also appeared on comp.lang.python quite a few times lately -- and no, I'm not confusing "comp.lang.python" with "most people" either) I do think it's a problem that Python advocates suffer from a "everything's perfect all the time" attitude. "it ain't broke because we say so". I think it's a larger problem that Python developers suffer from the same attitude; in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. </F>

Reinhold Birkenfeld wrote:

What is wrong with something like this:

...

...

...

class Quitter: ... def __repr__(self): raise SystemExit ... exit = quit = Quitter()

...

...

vars() # oops!

</F>