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 :)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
