This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mb_
Recipients SilentGhost, barry, mb_, ncoghlan, rhettinger, yselivanov
Date 2016-08-20.17:45:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471715110.75.0.81083619258.issue27814@psf.upfronthosting.co.za>
In-reply-to
Content
>and instead point you towards https://bugs.python.org/issue12029 

Fair enough.
But how would a 'suppress OSError, but catch FileNotFoundError' look like with this for example?
(Note that I can't subclass the exception)

>I'm also not sure it's an idiom we really want to encourage, as it tends to age poorly as new exception subclasses are added,

I partially agree. But there's one important spot where I need this behaviour: It is cleanup paths where I cannot react to most exceptions. For example because I already am handling exceptions and am already trying to tear the whole thing down anyway.

>as well as confusing exception flow logic like the example given in the documentation

I disagree.
The control flow does not change with this patch at all.
It either pops out of the with-statement with an exception, or it does not.
The only thing this patch does is _reduce_ the set of exceptions it suppresses.

>For folks that do need this capability, building it themselves is pretty straightforward, 

Nah. The whole point of contextlib.suppress is to avoid boilerplate code. People could do their own stuff. In fact, that is what I did. But I prefer a standard solution in the standard library for this really common problem instead.
History
Date User Action Args
2016-08-20 17:45:10mb_setrecipients: + mb_, barry, rhettinger, ncoghlan, SilentGhost, yselivanov
2016-08-20 17:45:10mb_setmessageid: <1471715110.75.0.81083619258.issue27814@psf.upfronthosting.co.za>
2016-08-20 17:45:10mb_linkissue27814 messages
2016-08-20 17:45:10mb_create