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')
I think you meant
class _Quitter(str):
def __call__(self): raise SystemExit
(for those who follow non-python forums
make that those who don't follow
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
(for those who follow non-python forums
Fredrik make that those who don't follow
What might some of those non-python forums be?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
[EMAIL PROTECTED] 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
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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/
Given that C++
On 12/29/05, Aahz [EMAIL PROTECTED] wrote:
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?
Nobody reads that; plus it looks like it's
Aahz wrote:
Does that also include my suggestion about improving the startup message?
when newbies get to the point that they want to quit, chances are
that the message have scrolled out of sight. and if they only skim
the instructions, they'll probably get confused anyway... e.g.
Python
Walter Dörwald wrote:
Alex Martelli wrote:
On 12/28/05, Walter Dörwald [EMAIL PROTECTED] 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
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
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
The F-bot writes:
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
Michael Chermside wrote:
Seriously... I've seen this behavior also, but I haven't ever thought
about it as clearly as Fredrik does here. When we go to answer questions
we ought to pause briefly first and decide which of these categories
applies to a given piece of behavior. I think users will
Michael Chermside wrote:
The F-bot writes:
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
Aahz wrote:
On Wed, Dec 28, 2005, Brett Cannon wrote:
On 12/28/05, Aahz [EMAIL PROTECTED] wrote:
Here's yet a different take on this: .. change the startup message...
Type help, copyright, credits or license for more information.
Let's add another line that says
Type quit() to exit
Scott David Daniels [EMAIL PROTECTED] 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
Neil Schemenauer wrote:
Scott David Daniels [EMAIL PROTECTED] 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
Samuele Pedroni wrote:
Michael Chermside wrote:
The F-bot writes:
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
Nick == Nick Coghlan [EMAIL PROTECTED] writes:
Nick Samuele Pedroni wrote:
It's not a matter of defending the status quo, more about what
kind of price is reasonable for DWIM.
IMHO, +N*10^6 for simplicity, regularity, and discoverability, -1 for
DWIM in the interpreter. DWIM is
[EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] 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
Martin v. Löwis 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
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,
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
Jeremy Kloth wrote:
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
Martin v. Löwis wrote:
Introducing sys.commandline is fine; overriding sys.excepthook
still worrisome.
What's wrong with triggering this in some __repr__ implementation?
because simple introspection may exit your program. unexpected
exits are a lot more annoying than unexpected non-exits.
[EMAIL PROTECTED] 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
Michael Hudson wrote:
[EMAIL PROTECTED] 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
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
Fredrik Lundh [EMAIL PROTECTED] writes:
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
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
Fredrik if isinstance(exc_value, NameError) and not exc_info.tb_next:
Fredrik text = exc_value[0]
Fredrik name = ... extract name from nameerror string ...
Fredrik if sys.commandline.strip() == name:
Fredrik if name in (exit, quit):
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
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.
That would assume that the user knows that exit is a function:
apparently, people
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
[EMAIL PROTECTED] 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
Alex Martelli wrote:
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
[EMAIL PROTECTED] 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
[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
On 12/28/05, Walter Dörwald [EMAIL PROTECTED] 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
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,
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 --
[Alex Martelli]
On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote:
[EMAIL PROTECTED] writes:
Fredrik a quit/exit command that actually quits, instead of
Fredric printing a you didn't say please! message.
I like Fredrik's idea more and more.
The thing that bothers me about it is
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
Reinhold Birkenfeld wrote:
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
Martin == Martin v Löwis [EMAIL PROTECTED] 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
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
On 12/27/05, Fredrik Lundh [EMAIL PROTECTED] 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
Guido van Rossum 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
Guido van Rossum wrote:
On 12/27/05, Fredrik Lundh [EMAIL PROTECTED] 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.
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
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
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. For example, I already use an excepthook in interactive
mode to try to resolve NameErrors:
%
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
Reinhold Birkenfeld wrote:
What is wrong with something like this:
class Quitter:
... def __repr__(self): raise SystemExit
...
exit = quit = Quitter()
vars() # oops!
/F
___
Python-Dev mailing list
Python-Dev@python.org
On 12/28/05, Reinhold Birkenfeld [EMAIL PROTECTED] 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
Fredrik Lundh wrote:
Reinhold Birkenfeld wrote:
What is wrong with something like this:
class Quitter:
... def __repr__(self): raise SystemExit
...
exit = quit = Quitter()
vars() # oops!
You're right.
class Quitter:
... def __repr__(self):
... n =
On 27-dec-2005, at 14:55, Christopher Armstrong wrote:
On 12/28/05, Reinhold Birkenfeld reinhold-birkenfeld-
[EMAIL PROTECTED] 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.
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):
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
Ronald Oussoren wrote:
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
Martin So if they do
quit
function quit at 0xb7d96294
Martin they are just as confused as if they got a name error.
Probably more so... wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] 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
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
Hans Nowak wrote:
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
Fredrik Lundh wrote:
(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 ?)
I believe checking sys.argv==[''] is a nearly reliable test (the only
other case where I could make it happen is when the script is
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
[Martin v. Löwis]
If you want to type something consistently across platforms, you can
currently do
raise SystemExit
[Hans Nowak]
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
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
Hans Nowak wrote:
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?)
Well... I
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.
Beside, it
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
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin. So why not do that?
I see two options. Either:
(a) Simply let __builtins__.exit = sys.exit. Then we get:
exit
built-in function exit
which may be enough of a clue
On Wednesday, December 28, 2005 Fredrik Lundh wrote:
WinXP or WinXP+Cygwin ? here's what I get:
Normal WinXP, without Cygwin.
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
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
On 12/27/05, Ka-Ping Yee [EMAIL PROTECTED] wrote:
It sounds to me like what is being proposed amounts to essentially
promote sys.exit to a builtin. So why not do that?
I see two options. Either:
(a) Simply let __builtins__.exit = sys.exit. Then we get:
exit
Ka-Ping Yee 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
that actually quits, instead of printing a you didn't say please! message.
/F
-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 'Type exit() to exit Python.'
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
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
On Wed, 28 Dec 2005, Fredrik Lundh wrote:
Ka-Ping Yee 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
that actually quits, instead of printing a you didn't say
Ka-Ping Yee wrote:
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]
79 matches
Mail list logo
