<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 04.06.2018 23:52, Ivan Pozdeev wrote:<br>
<blockquote type="cite"
cite="mid:f4cb48d2-73c3-152f-8f17-95c86d6981aa@mail.mipt.ru">On
04.06.2018 20:11, Chris Angelico wrote:
<br>
<blockquote type="cite">On Tue, Jun 5, 2018 at 2:57 AM, Yury
Selivanov <a class="moz-txt-link-rfc2396E" href="mailto:yselivanov.ml@gmail.com"><yselivanov.ml@gmail.com></a> wrote:
<br>
<blockquote type="cite">On Mon, Jun 4, 2018 at 12:50 PM Chris
Angelico <a class="moz-txt-link-rfc2396E" href="mailto:rosuav@gmail.com"><rosuav@gmail.com></a> wrote:
<br>
<blockquote type="cite">On Tue, Jun 5, 2018 at 2:11 AM, Victor
Stinner <a class="moz-txt-link-rfc2396E" href="mailto:vstinner@redhat.com"><vstinner@redhat.com></a> wrote:
<br>
</blockquote>
[..]
<br>
<blockquote type="cite">
<blockquote type="cite">For me, it's fine to catch any
exception using "except:" if the block
<br>
contains "raise", typical pattern to cleanup a resource in
case of
<br>
error. Otherwise, there is a risk of leaking open file or
not flushing
<br>
data on disk, for example.
<br>
</blockquote>
Pardon the dumb question, but why is try/finally unsuitable?
<br>
</blockquote>
Because try..finally isn't equivalent to try..except? Perhaps
you
<br>
should look at the actual code:
<br>
<a class="moz-txt-link-freetext" href="https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123">https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123</a>
<br>
</blockquote>
</blockquote>
</blockquote>
<p>In this particular code, it looks like just KeyboardInterrupt
needs to be handled in addition to Exception -- and even that's
not certain 'cuz KeyboardInterrupt is an abnormal termination and
specifically designed to not be messed with by the code ("The
exception inherits from <a class="reference internal"
href="https://docs.python.org/3/library/exceptions.html?highlight=generatorexit#BaseException"
title="BaseException"><code class="xref py py-exc docutils
literal notranslate"><span class="pre">BaseException</span></code></a>
so as to not be
accidentally caught by code that catches <a class="reference
internal"
href="https://docs.python.org/3/library/exceptions.html?highlight=generatorexit#Exception"
title="Exception"><code class="xref py py-exc docutils literal
notranslate"><span class="pre">Exception</span></code></a> and
thus prevent
the interpreter from exiting."). It only makes sense to catch it
in REPL interfaces where the user clearly wants to terminale the
current command rather than the entire program.<br>
</p>
<p>If e.g. a warning is upgraded to exception, this means that some
code is broken from user's POV, but not from Python team's POV, so
we can't really be sure if we can handle this situation
gracefully: our cleanup code can fail just as well!<br>
</p>
<blockquote type="cite"
cite="mid:f4cb48d2-73c3-152f-8f17-95c86d6981aa@mail.mipt.ru">
<blockquote type="cite">Oh. Duh. Yep, it was a dumb question.
Sorry! The transport should ONLY
<br>
be closed on error.
<br>
</blockquote>
<br>
I smell a big, big design violation here.
<br>
The whole point of Exception vs BaseException is that anything not
Exception is "not an error", has a completely different effect on
the program than an error, and thus is to be dealt with completely
differently. For example, warnings do not disrupt the control
flow, and GeneratorExit is normally handled by the `for` loop
machinery.
<br>
That's the whole point why except: is strongly discouraged.
<br>
<br>
Be _very_ careful because when a system has matured, the risk of
making bad to disastrous design decisions skyrockets (because "the
big picture" grows ever larger, and it's ever more difficult to
account for all of it).
<br>
<br>
The best solution I know of is an independent sanity-check against
the project's core design principles: focus solely on them and say
if the suggestion is in harmony with the existing big picture.
This prevents the project from falling victim to
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Design_by_committee">https://en.wikipedia.org/wiki/Design_by_committee</a> in the long run.
This is easier to do for someone not intimately involved with the
change and the affected area 'cuz they are less biased in favor of
the change and less distracted by minute details.
<br>
<br>
Someone may take up this role to "provide a unified vision" (to
reduce the load on a single
<a class="moz-txt-link-freetext" href="http://meatballwiki.org/wiki/BenevolentDictator">http://meatballwiki.org/wiki/BenevolentDictator</a> , different
projects have tried delegates (this can run afoul of
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Conway%27s_law">https://en.wikipedia.org/wiki/Conway%27s_law</a> though) and a
round-robin approach (Apache)).
<br>
The best way, however, would probably be for anyone dealing with a
design change to remember to make this check.
<br>
<br>
This is even easier in Python, 'cuz the core values are officially
formulated as Python Zen, and any module has one or two governing
principles at its core, tops, that can be extracted by skimming
through its docs.
<br>
<br>
<blockquote type="cite">ChrisA
<br>
_______________________________________________
<br>
Python-Dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a>
<br>
Unsubscribe:
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru">https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>