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 :)
   ">

(original) (raw)

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 :)