<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<div class="moz-cite-prefix">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:<br>
<br>
- you learn how to walk before you understand the musculoskeletal
physics<br>
- you learn how to turn on/off the lights before you understand
how electricity works<br>
- you learn how to drive before you learn how/why a vehicle works<br>
- you learn how to speak before you understand how grammar works<br>
- you learn how to locate the constellations before you understand
interplanetary gravitational forces<br>
- many, many, many, many more things<br>
<br>
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?"<br>
<br>
What it doesn't do, though is address the dubious part of the
whole construct, which is composition.<br>
<br>
On 10/17/2013 8:26 AM, Nick Coghlan wrote:<br>
</div>
<blockquote
cite="mid:CADiSq7epAnJZiQLp7q_E33e++rUmQfENDLbGJO9-Mbn+k0dzig@mail.gmail.com"
type="cite">
<pre wrap="">And even a two line version:
with suppress(FileNotFoundError): os.remove("somefile.tmp")
with suppress(FileNotFoundError): os.remove("someotherfile.tmp")</pre>
</blockquote>
<br>
The above example, especially if extended beyond two files, begs to
used in a loop, like your 5 line version:<br>
<br>
for name in ("somefile.tmp", "someotherfile.tmp"):<br>
with suppress(FileNotFoundError):<br>
os.remove(name)<br>
<br>
which would be fine, of course.<br>
<br>
But to some with less education about the how and why, it is not
clear why it couldn't be written like:<br>
<br>
with suppress(FileNotFoundError):<br>
for name in ("somefile.tmp", "someotherfile.tmp"):<br>
os.remove(name)<br>
<br>
yet to the cognoscenti, it is obvious there are seriously different
semantics.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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". <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
My conclusion: suppress considered harmful, hidden goto within :)<br>
</body>
</html>