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

[Glenn Linderman]

First, thanks for the education. What you wrote is extremely edifying 
about more than just context managers, and I really appreciate the 
visionary understanding you reported from BrisPy and further elucidated 
on, regarding the educational pattern of using things before you learn 
how they work... that applies strongly in arenas other than programming 
as well:

- you learn how to walk before you understand the musculoskeletal physics
- you learn how to turn on/off the lights before you understand how 
electricity works
- you learn how to drive before you learn how/why a vehicle works
- you learn how to speak before you understand how grammar works
- you learn how to locate the constellations before you understand 
interplanetary gravitational forces
- many, many, many, many more things

And of course, many people never reach the understanding of how or why 
for many things they commonly use, do, or observe. That's why some 
people make things happen, some people watch what happens, and some 
people wonder "What happened?"

What it doesn't do, though is address the dubious part of the whole 
construct, which is composition.

On 10/17/2013 8:26 AM, Nick Coghlan wrote:
> And even a two line version:
>
>      with suppress(FileNotFoundError): os.remove("somefile.tmp")
>      with suppress(FileNotFoundError): os.remove("someotherfile.tmp")

The above example, especially if extended beyond two files, begs to used 
in a loop, like your 5 line version:

for name in ("somefile.tmp", "someotherfile.tmp"):
        with suppress(FileNotFoundError):
                 os.remove(name)

which would be fine, of course.

But to some with less education about the how and why, it is not clear 
why it couldn't be written like:

with suppress(FileNotFoundError):
         for name in ("somefile.tmp", "someotherfile.tmp"):
                 os.remove(name)

yet to the cognoscenti, it is obvious there are seriously different 
semantics.

In my own code, I have a safe_delete function to bundle the exception 
handling and the os.remove, and when factored that way, the temptation 
to nest the loop inside the suppress is gone. With suppress available, 
though, and if used, the temptation to factor it, either correctly or 
incorrectly, appears. How many cut-n-paste programmers will get it right 
and how many will get it wrong, is the serious question here, I think, 
and while suppress is a slightly better term than ignore, it still hides 
the implications to the control flow when an exception is actually 
raised within the block.

I'm still dubious that the benefits of this simpler construct, while an 
interesting composition of powerful underlying constructs, has 
sufficient benefit to outweigh the naïve user's potential for misusing 
it (exacerbated by a name that doesn't imply control flow), or even the 
extra cost in performance per the microbenchmark someone published.

Your more complex examples for future versions may have greater merit 
because they provide a significantly greater reduction in complexity to 
offset the significantly greater learning curve required to use and 
understand them. But even those look like an expensive form of goto (of 
course, goto is considered harmful, and I generally agree with the 
reasons why, but have coded them in situations where they are more 
useful than harmful in languages which support them).

I imagine that everyone on python-dev is aware that most of the control 
flow constructs in structured programming (which is a subset of OO) are 
to control the context of the CPUs "instruction pointer" without the use 
of "goto".

The real problem with "goto" is not that the instruction pointer is 
changed non-sequentially, but that arbitrary changes can easily violate 
poorly documented preconditions of the target location. Hence, 
structured programming is really an attempt to avoid writing 
documentation, a laudable goal as the documentation is seldom sufficient 
at that level of detail... or if sufficient, is repetitive and 
overwhelming to create, maintain, and comprehend. It achieves that by 
making control flow constructs that are "higher level" than goto, that 
have meanings that can be understood and explained in educational texts, 
which then are implicit documentation for those control flow aspects of 
a particular program. OO builds on structured programming to make neat 
packages of state and control flow, to isolate state into understandable 
chunks so that larger programs can be comprehended, as the BrisPy 
presenter enlightened us, without understanding all the details of how 
each object and function within it works.

Programmers raised on OO and GUI toolkits are building more and more 
systems out of more complex parts, which increases productivity, and 
that is good, although when they fail to fully understand the parts, 
some "interesting" performance characteristics can result.

ignore/suppress seems to me to be a sledge hammer solution for driving a 
tack. The tack may be driven successfully, but the potential for damage 
to the surroundings (by misunderstanding the control flow implications) 
is sufficient to make me dubious regarding its overall value. Adequate 
documentation may help (if it is both provided and read), but the best 
constructs are those that are self-documenting, or well documented in 
existing "programming 101" books. I haven't seen this construct in other 
languages, nor has such a comparison been made in this thread, so I 
consider the potential for misuse large.

My conclusion: suppress considered harmful, hidden goto within :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131017/6119f28a/attachment.html>