Frederick suggested a change to quit/exit a while ago, so it wasn't just a string with slight instructional purpose, but actually useful. The discussion was surprisingly involved, despite the change really trully not being that big. And everyone drifted off, too tired from the discussion to make a change. I suppose it didn't help that the original proposal struck some people as too magic, while there were some more substantive problems brought up as well, and when you mix aesthetic with technical concerns everyone gets all distracted and worked up. Anyway, I would like to re-propose one of the ideas that came up (originally from Ping?):
class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() quit = Quitter('quit') exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current behavior. It does not satisfy the "just do what I said" argument for not requiring the call (quit() not quit), but eh -- I guess it seemed like everything that didn't require a call had some scary corner case where the interpreter would abruptly exit.
Works for me.
On 3/7/06, Ian Bicking ianb@colorstudy.com wrote:
Frederick suggested a change to quit/exit a while ago, so it wasn't just a string with slight instructional purpose, but actually useful. The discussion was surprisingly involved, despite the change really trully not being that big. And everyone drifted off, too tired from the discussion to make a change. I suppose it didn't help that the original proposal struck some people as too magic, while there were some more substantive problems brought up as well, and when you mix aesthetic with technical concerns everyone gets all distracted and worked up. Anyway, I would like to re-propose one of the ideas that came up (originally from Ping?):
class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() quit = Quitter('quit') exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current behavior. It does not satisfy the "just do what I said" argument for not requiring the call (quit() not quit), but eh -- I guess it seemed like everything that didn't require a call had some scary corner case where the interpreter would abruptly exit.
-- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org _______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Ian Bicking wrote:
class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() quit = Quitter('quit') exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current behavior. It does not satisfy the "just do what I said" argument for not requiring the call (quit() not quit), but eh -- I guess it seemed like everything that didn't require a call had some scary corner case where the interpreter would abruptly exit.
It also nicely aligns with the way that license() and help() already work at the interactive prompt.
Cheers, Nick.
do { cmd = readline() do_stuff_with_cmd(cmd); } while (!strcmp(cmd, "quit")); printf("Bye!"); exit(0);
KISS?
-- mvh Björn
I am probably the biggest proponent of magic variables, but this just won't work. First, commands and lines are not the same thing, so:
print \ exit
breaks your propossal.
Second, quit and exit are bindable variables, and you need to be sure that they still mean _quit_, and not something else.
On 3/7/06, BJörn Lindqvist bjourne@gmail.com wrote:
do { cmd = readline() do_stuff_with_cmd(cmd); } while (!strcmp(cmd, "quit")); printf("Bye!"); exit(0);
KISS?
-- mvh Björn _______________________________________________ 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/crutcher%40gmail.com
-- Crutcher Dunnavant crutcher@gmail.com littlelanguages.com monket.samedi-studios.com
BJörn Lindqvist wrote:
do { cmd = readline() do_stuff_with_cmd(cmd); } while (!strcmp(cmd, "quit")); printf("Bye!"); exit(0);
KISS?
I believe there were concerns that rebinding quit would cause strange behavior. E.g.:
quit = False while not quit: ... quit
$
Or:
if raw_input('quit?') == 'yes':
... quit
will that work? Should it? Functions are pretty predictable in comparison to these other options. So, at least to me, quit() == KISS
On 3/7/06, Ian Bicking ianb@colorstudy.com wrote:
Frederick suggested a change to quit/exit a while ago, so it wasn't just a string with slight instructional purpose, but actually useful. The discussion was surprisingly involved, despite the change really trully not being that big. And everyone drifted off, too tired from the discussion to make a change. I suppose it didn't help that the original proposal struck some people as too magic, while there were some more substantive problems brought up as well, and when you mix aesthetic with technical concerns everyone gets all distracted and worked up. Anyway, I would like to re-propose one of the ideas that came up (originally from Ping?):
class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() quit = Quitter('quit') exit = Quitter('exit')
This is not very magical, but I think is more helpful than the current behavior. It does not satisfy the "just do what I said" argument for not requiring the call (quit() not quit), but eh -- I guess it seemed like everything that didn't require a call had some scary corner case where the interpreter would abruptly exit.
+1 from me. Only change I would make is pass an argument to SystemExit() such as "%s() called", although the chances of this exception being caught is very slim.
-Brett
On 3/8/06, Brett Cannon brett@python.org wrote:
On 3/7/06, Ian Bicking ianb@colorstudy.com wrote:
class Quitter(object): def __init__(self, name): self.name = name def __repr__(self): return 'Use %s() to exit' % self.name def __call__(self): raise SystemExit() quit = Quitter('quit') exit = Quitter('exit')
+1 from me. Only change I would make is pass an argument to SystemExit() such as "%s() called", although the chances of this exception being caught is very slim.
Raising SystemExit("quit() called") has an additional benefit (although the wording could use some work):
raise SystemExit("quit() called")
quit() called
(At least, I consider that a benefit :-) -- Thomas Wouters thomas@python.org
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Wed, Mar 08, 2006 at 12:37:47AM +0100, Thomas Wouters wrote:
Raising SystemExit("quit() called") has an additional benefit (although the wording could use some work):
raise SystemExit("quit() called")
quit() called
(At least, I consider that a benefit :-)
It has a bad side-effect of returning an error code to the calling shell:
$ python && echo Ok || echo Error! Python 2.4.2 (#1, Oct 3 2005, 20:57:52) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
raise SystemExit("quit() called")
quit() called Error!
(At least, I consider that a bad side-effect.)
Oleg.
Oleg Broytmann wrote:
On Wed, Mar 08, 2006 at 12:37:47AM +0100, Thomas Wouters wrote:
Raising SystemExit("quit() called") has an additional benefit (although the wording could use some work):
raise SystemExit("quit() called")
quit() called
(At least, I consider that a benefit :-)
It has a bad side-effect of returning an error code to the calling shell:
$ python && echo Ok || echo Error! Python 2.4.2 (#1, Oct 3 2005, 20:57:52) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
raise SystemExit("quit() called")
quit() called Error!
(At least, I consider that a bad side-effect.)
I should imagine the use cases for running an interactive Python shell as a part of a script are fairly few and far between, though.
regards Steve
On Wed, Mar 08, 2006 at 12:39:51PM +0000, Steve Holden wrote:
Oleg Broytmann wrote:
raise SystemExit("quit() called")
quit() called Error!
I should imagine the use cases for running an interactive Python shell as a part of a script are fairly few and far between, though.
IDEs. Edit a code in an editor, run python -i script.py, investigate the environment, return to the editor, get error message.
Oleg.
Oleg Broytmann wrote:
IDEs. Edit a code in an editor, run python -i script.py, investigate the environment, return to the editor, get error message.
An IDE is likely to want to catch SystemExits in the debugged script and handle them specially anyway.
We seem to have a consensus. Is anybody working on a patch yet?
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
We seem to have a consensus. Is anybody working on a patch yet?
Georg
On 3/7/06, Thomas Wouters thomas@python.org wrote:
+1 from me. Only change I would make is pass an argument to SystemExit() such as "%s() called", although the chances of this exception being caught is very slim.
Raising SystemExit("quit() called") has an additional benefit (although the wording could use some work):
raise SystemExit("quit() called")
quit() called
(At least, I consider that a benefit :-)
Bad idea, as several pointed out -- quit() should return a 0 exit to the shell.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum guido@python.org wrote:
Bad idea, as several pointed out -- quit() should return a 0 exit to the shell.
I like the idea of making "quit" callable. One small concern I have is that people will use it in scripts to exit (rather than one of the other existing ways to exit). OTOH, maybe that's a feature.
Neil
Neil Schemenauer wrote:
Bad idea, as several pointed out -- quit() should return a 0 exit to the shell.
I like the idea of making "quit" callable. One small concern I have is that people will use it in scripts to exit (rather than one of the other existing ways to exit). OTOH, maybe that's a feature.
I actually thought it was only defined for interactive sessions, but a brief test shows I was wrong. It doesn't bother me, but it does make me think that exit(1) should exit with a code of one.
Ian Bicking ianb@colorstudy.com wrote:
Neil Schemenauer wrote:
Bad idea, as several pointed out -- quit() should return a 0 exit to the shell.
I like the idea of making "quit" callable. One small concern I have is that people will use it in scripts to exit (rather than one of the other existing ways to exit). OTOH, maybe that's a feature.
I actually thought it was only defined for interactive sessions, but a brief test shows I was wrong. It doesn't bother me, but it does make me think that exit(1) should exit with a code of one.
Sounds like the quit/exit bits are becoming aliases for sys.exit with special docstrings. That would be fine with me.
- Josiah
-
BJörn Lindqvist -
Brett Cannon -
Crutcher Dunnavant -
Georg Brandl -
Greg Ewing -
Guido van Rossum -
Ian Bicking -
Josiah Carlson -
Neil Schemenauer -
Nick Coghlan -
Oleg Broytmann -
Steve Holden -
Thomas Wouters