[Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore(). (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Oct 12 01:06:24 CEST 2013

On 12 Oct 2013 03:58, "R. David Murray" <rdmurray at bitdance.com> wrote:

On Fri, 11 Oct 2013 20:32:45 +0300, Serhiy Storchaka <storchaka at 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 at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131012/55917df6/attachment.html>

More information about the Python-Dev mailing list