> 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
Nick Coghlan wrote:
> 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 -- bu
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
> "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 interpret
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
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 exi
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
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
>>>
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
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 wi
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
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 als
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 fi
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 cl
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 lik
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 ver
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
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
[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 bac
>> (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
Unsu
> (for those who follow non-python forums
make that "those who don't follow"
___
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/archive
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 be able to define
Steve Holden wrote:
> I *have* been surprised by the amount on brainpower that's been
> expended on this discussion.
number of posts != amount of brainpower
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
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
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 ru
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
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 Pytho
On Wed, Dec 28, 2005, Brett Cannon wrote:
> On 12/28/05, Aahz <[EMAIL PROTECTED]> 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.
On 12/28/05, Aahz <[EMAIL PROTECTED]> 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", "copyri
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'
> "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!
Martin> or they are entirely unaware of
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
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 all
[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 bother
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 brainstorm
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 "qui
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
> > cur
[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
>> impl
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
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
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, peop
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
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
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?
"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 t
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.
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 te
[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
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
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 ex
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
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,
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
[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 hackis
[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 EO
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,
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'
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
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
>abo
-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__.qui
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.
_
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
>
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. Ple
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.
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
which may be enough of a clue that you type "exit
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 X
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.
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
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
[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 p
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 somet
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
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 no
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 Py
[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> So if they do
>>> quit
Martin> they are just as confused as if they got a name error.
Probably more so...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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
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):
>> r
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 __cal
On 27-dec-2005, at 14:55, Christopher Armstrong wrote:
> 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 si
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 = s
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
Reinhold Birkenfeld wrote:
> What is wrong with something like this:
>
> >>> class Quitter:
> ... def __repr__(self): raise SystemExit
> ...
> >>> exit = quit = Quitter()
>>> vars() # oops!
___
Python-Dev mailing list
Python-Dev@python.org
http:/
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
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:
% pytho
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
86 matches
Mail list logo
