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

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