I might agree with idea of contextlib.ignore() (I'm still opposed to
the idea), but I don't understand the purpose of adding a new syntax
doing exactly the same than try/except:
> with trap(OSError) as cm:
> os.unlink('missing.txt')
> if cm.exc:
> do_something()
Nobody noticed that this can be written:
try:
os.unlink('missing.txt')
except OSError as err:
# do something with err
?? What happened with the Zen Principle "There should be one-- and
preferably only one --obvious way to do it." I don't understand why I
would import contextlib and use a new context manager, whereas
try/except is already a builtin feature of Python.
By the way, what are the performances of contextlib.ignore()?
Exceptions can be slow in some cases. Adding something even slower
would not be a good idea.
Victor
2013/10/15 Tim Delaney <timothy.c.dela...@gmail.com>:
> On 16 October 2013 05:17, Alexander Belopolsky
> <alexander.belopol...@gmail.com> wrote:
>>
>> On Tue, Oct 15, 2013 at 12:45 PM, Ethan Furman <et...@stoneleaf.us> wrote:
>> > with trap(OSError) as cm:
>> > os.unlink('missing.txt')
>> > if cm.exc:
>> > do_something()
>>
>> .. and why is this better than
>>
>> try:
>> os.unlink('missing.txt')
>> except OSError as exc:
>> do_something()
>
>
> It would allow you to perform a series of operations then process the any
> exceptions all together e.g.
>
> with trap(OSError) as cm1:
> os.unlink('missing.txt')
>
> with trap(OSError) as cm2:
> os.unlink('other_missing.txt')
>
> with trap(OSError) as cm3:
> os.unlink('another_missing.txt')
>
> for cm in (cm1, cm2, cm3):
> if cm.exc:
> do_something(cm.exc)
>
> An equivalent implementation would be:
>
> exceptions = []
>
> try:
> os.unlink('missing.txt')
> except OSError as exc:
> exceptions.append(exc)
>
> try:
> os.unlink('missing.txt')
> except OSError as exc:
> exceptions.append(exc)
>
> try:
> os.unlink('missing.txt')
> except OSError as exc:
> exceptions.append(exc)
>
> for exc in exceptions:
> if exc:
> do_something(exc)
>
> Tim Delaney
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
