<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>