<p dir="ltr"><br>
On 16 Oct 2013 01:54, "R. David Murray" <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br>
><br>
> On Tue, 15 Oct 2013 22:57:34 +1000, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > On 15 October 2013 22:27, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > > Le Tue, 15 Oct 2013 22:05:41 +1000,<br>
> > > Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> a écrit :<br>
> > ><br>
> > >> On 15 October 2013 13:12, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com">v+python@g.nevcal.com</a>><br>
> > >> wrote:<br>
> > >> > Of course, if the name were changed to be accurate, or the feature<br>
> > >> > made less prone to misuse, then maybe it would terminate.<br>
> > >><br>
> > >> I've come to the conclusion it makes sense to rename it from ignore to<br>
> > >> suppress, since that's the term already used for this operation in the<br>
> > >> rest of the context management docs: <a href="http://bugs.python.org/issue19266">http://bugs.python.org/issue19266</a><br>
> > ><br>
> > > "suppress" and/or "trap" (which I believe is a common name for such<br>
> > > operation).<br>
> ><br>
> > I chose the new name based on the terminology used in the existing<br>
> > docs (I'll grant that a lot of these docs were written by me at<br>
> > various points in time, but taken together they still create a solid<br>
> > precedent that "suppress" refers to discarding the exception, while<br>
> > "trap" just refers to catching it and then potentially doing something<br>
> > with it, including reraising it).<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/stdtypes.html#contextmanager.__exit__">http://docs.python.org/dev/library/stdtypes.html#contextmanager.__exit__</a>:<br>
> ><br>
> > "Exit the runtime context and return a Boolean flag indicating if any<br>
> > exception that occurred should be suppressed."<br>
> ><br>
> > "Returning a true value from this method will cause the with statement<br>
> > to suppress the exception and continue execution with the statement<br>
> > immediately following the with statement. "<br>
><br>
> Someone could read this and reason by analogy: "so if the *context<br>
> manager* is named suppress, then execution will resume following the<br>
> statement where the exception was suppressed". They'd be wrong, of<br>
> course, I'm just pointing out some confusion that we might still see.<br>
><br>
> > From <a href="http://docs.python.org/dev/reference/datamodel.html#object.__exit__">http://docs.python.org/dev/reference/datamodel.html#object.__exit__</a><br>
> ><br>
> > "If an exception is supplied, and the method wishes to suppress the<br>
> > exception (i.e., prevent it from being propagated), it should return a<br>
> > true value."<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.contextmanager">http://docs.python.org/dev/library/contextlib#contextlib.contextmanager</a><br>
> ><br>
> > "If an exception is trapped merely in order to log it or to perform<br>
> > some action (rather than to suppress it entirely), the generator must<br>
> > reraise that exception."<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.ignore">http://docs.python.org/dev/library/contextlib#contextlib.ignore</a> (!)<br>
> ><br>
> > "As with any other mechanism that completely suppresses exceptions, it<br>
> > should only be used to cover very specific errors where silently<br>
> > ignoring the exception is known to be the right thing to do."<br>
><br>
> This should emphasize that execution resumes with the statement following<br>
> the with block, and give that as a strong motivation for only using it<br>
> to cover the line where the exception is to be suppressed (and there are<br>
> likely to be very few cases where it would reasonable for it to be more<br>
> than one line, and that is probably worth pointing out).<br>
><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.ExitStack">http://docs.python.org/dev/library/contextlib#contextlib.ExitStack</a><br>
> ><br>
> > "...if an inner callback suppresses or replaces an exception, then<br>
> > outer callbacks will be passed arguments based on that updated state."<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.enter_context">http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.enter_context</a><br>
> ><br>
> > "These context managers may suppress exceptions just as they normally<br>
> > would if used directly as part of a with statement."<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.push">http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.push</a><br>
> ><br>
> > "By returning true values, these callbacks can suppress exceptions the<br>
> > same way context manager __exit__() methods can."<br>
> ><br>
> > From <a href="http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.callback">http://docs.python.org/dev/library/contextlib#contextlib.ExitStack.callback</a><br>
> ><br>
> > "Unlike the other methods, callbacks added this way cannot suppress<br>
> > exceptions (as they are never passed the exception details)."<br>
> ><br>
> > So, having been convinced that "ignore" was the wrong choice of name,<br>
> > reviewing the docs made it clear to me what the name *should* be.<br>
><br>
> I think 'trap' would be much clearer. What about making the context<br>
> manager provide the trapped exception, in a fashion similar to<br>
> what assertRaises does? Even if that was almost never used in practice,<br>
> the fact that the CM provides only *one* exception no matter how<br>
> many statements are in the with block would strongly reinforce the<br>
> actual semantics of the construct. It would also make it parallel to<br>
> assertRaises, which seems like a consistency bonus.<br>
><br>
> And I could see it getting used. I think I've had code where the logic<br>
> was: possibly trap an exception, stuff it in a variable, do some logic,<br>
> check the variable to see if we had an exception earlier, and if so do<br>
> something with it or otherwise branch the logic. I won't say this is<br>
> common, and I won't say there wouldn't often be a better way to write<br>
> it...but I can think that it might have utility.</p>
<p dir="ltr">Yes, something along those lines is exactly what I plan to explore for 3.5. It's a completely orthogonal question, though - suppress is specifically an up front statement of intent for the case where you genuinely don't care if the exception gets raised or not. </p>
<p dir="ltr">With suppress already available, the more general construct can be designed specifically for the case where you *do* care if the exception was raised or not.</p>
<p dir="ltr">By contrast, providing only the more general construct would mean that "I don't care if an exception is raised or not" would be implied solely by the absence of an "as" clause, which is a very poor way to communicate intent.</p>
<p dir="ltr">> With that change, I'd be +1. With just suppress, I'm -0.</p>
<p dir="ltr">Please, please, please just let it drop. Even though it eventually convinced me to change the name, this thread still epitomises everything that sucks about soul destroying, energy draining bikeshed painting that makes me wonder why I ever bother trying to make anything better.</p>
<p dir="ltr">Regards,<br>
Nick.</p>
<p dir="ltr">><br>
> --David<br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
><br>
</p>