I'm not too fussy about the name (clearly). We originally picked ignored(), Raymond asked if he could change it to ignore() (and I said yes), and there's a valid argument to be made that closing() sets the precedent that it should be ignoring(). (RDM is also right that the exception still has the effect of terminating the block early, but I view names as mnemonics rather than necessarily 100% accurate descriptions of things).

">

(original) (raw)


On 12 Oct 2013 03:58, "R. David Murray" <rdmurray@bitdance.com> wrote:
\>
\> On Fri, 11 Oct 2013 20:32:45 +0300, Serhiy Storchaka <storchaka@gmail.com> wrote:
\> > 11.10.13 10:24, Antoine Pitrou написав(ла):
\> > > Ezio was -1 on the tracker, and Eric Smith was -0\. I'd like to add my
\> > > -1 too. This is a useless addition (the traditional idiom is perfectly
\> > > obvious) and makes reading foreign code more tedious by adding
\> > > superfluous API calls.
\> >
\> > I am -1 too. But I want to hear more about interact with ExitStack (note
\> > that ExitStack itself is not widely used in the stdlib).
\>
\> I'm inclined to be -1 as well, because of the anti-pattern
\> encouragement. It seems at first blush like using it with ExitStack
\> would make that tendency worse, so I too would like to hear more about
\> Nick's thoughts on the subject.

In conjunction with ExitStack itself, I see it as a building block for dynamic exception handling, decoupled from the syntactic layout of code.

I also see reducing a four line idiom to a two line one that is easier to grep for as a benefit, as well as providing another place in the docs to nudge people towards improved exception handling practices (even if we didn't take advantage of that opportunity in the original patch). For example, a counterpart in logging that \*logged\* suppressed exceptions rather than ignoring them completely would be a good resource to point to, while being more discoverable than just offering the manager in logging (such a manager would \*also\* mix nicely with ExitStack).

I'm not too fussy about the name (clearly). We originally picked ignored(), Raymond asked if he could change it to ignore() (and I said yes), and there's a valid argument to be made that closing() sets the precedent that it should be ignoring(). (RDM is also right that the exception still has the effect of terminating the block early, but I view names as mnemonics rather than necessarily 100% accurate descriptions of things).

Cheers,
Nick.

>
\> --David
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> 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/ncoghlan%40gmail.com
\>