<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 05.06.2018 0:54, Ivan Pozdeev wrote:<br>
<blockquote type="cite"
cite="mid:c5697110-05e1-808e-3355-c03e6e0d5b8f@mail.mipt.ru">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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" moz-do-not-send="true"><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" moz-do-not-send="true"><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" moz-do-not-send="true"><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"
moz-do-not-send="true">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" moz-do-not-send="true"><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" moz-do-not-send="true"><code class="xref py
py-exc docutils literal notranslate"><span class="pre">Exception</span></code></a>
and thus prevent the interpreter from exiting."). </p>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:c5697110-05e1-808e-3355-c03e6e0d5b8f@mail.mipt.ru">
<p>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>
</blockquote>
Remembered `pip`, too -- there, it's justified by it working in
transactions.<br>
<blockquote type="cite"
cite="mid:c5697110-05e1-808e-3355-c03e6e0d5b8f@mail.mipt.ru">
<p> </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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">Python-Dev@python.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://mail.python.org/mailman/listinfo/python-dev"
moz-do-not-send="true">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"
moz-do-not-send="true">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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>