On 05.06.2018 0:54, Ivan Pozdeev wrote:
> On 04.06.2018 23:52, Ivan Pozdeev wrote:
>> On 04.06.2018 20:11, Chris Angelico wrote:
>>> On Tue, Jun 5, 2018 at 2:57 AM, Yury Selivanov
>>> <yselivanov.ml at gmail.com> wrote:
>>>> On Mon, Jun 4, 2018 at 12:50 PM Chris Angelico <rosuav at gmail.com>
>>>> wrote:
>>>>> On Tue, Jun 5, 2018 at 2:11 AM, Victor Stinner
>>>>> <vstinner at redhat.com> wrote:
>>>> [..]
>>>>>> For me, it's fine to catch any exception using "except:" if the
>>>>>> block
>>>>>> contains "raise", typical pattern to cleanup a resource in case of
>>>>>> error. Otherwise, there is a risk of leaking open file or not
>>>>>> flushing
>>>>>> data on disk, for example.
>>>>> Pardon the dumb question, but why is try/finally unsuitable?
>>>> Because try..finally isn't equivalent to try..except? Perhaps you
>>>> should look at the actual code:
>>>> https://github.com/python/cpython/blob/b609e687a076d77bdd687f5e4def85e29a044bfc/Lib/asyncio/base_events.py#L1117-L1123
>>>>
>
> 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 |BaseException|
> <https://docs.python.org/3/library/exceptions.html?highlight=generatorexit#BaseException>
> so as to not be accidentally caught by code that catches |Exception|
> <https://docs.python.org/3/library/exceptions.html?highlight=generatorexit#Exception>
> 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.
>
Remembered `pip`, too -- there, it's justified by it working in
transactions.
>
> 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!
>
>>> Oh. Duh. Yep, it was a dumb question. Sorry! The transport should ONLY
>>> be closed on error.
>>
>> I smell a big, big design violation here.
>> 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.
>> That's the whole point why except: is strongly discouraged.
>>
>> 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).
>>
>> 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
>> https://en.wikipedia.org/wiki/Design_by_committee 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.
>>
>> Someone may take up this role to "provide a unified vision" (to
>> reduce the load on a single
>> http://meatballwiki.org/wiki/BenevolentDictator , different projects
>> have tried delegates (this can run afoul of
>> https://en.wikipedia.org/wiki/Conway%27s_law though) and a
>> round-robin approach (Apache)).
>> The best way, however, would probably be for anyone dealing with a
>> design change to remember to make this check.
>>
>> 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.
>>
>>> ChrisA
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
>>
>
> --
> Regards,
> Ivan
--
Regards,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180605/5338995b/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4