I'm wondering if there is any support (tepid better than none) for the
following syntactic sugar:
silence:
........ block
------------------------->
try:
........block
except:
........pass
The logic here is that there are a ton of "except: pass" statements[1]
floating around in code that do not need to be there. Meanwhile, the
potential keyword 'silence' does not appear to be in significant use
as a variable[2], or an alternative keyword might be imagined
('quiet', 'hush', 'stfu') but I somewhat like the verbiness of
'silence' since that is precisely what it does to the block (that is,
you have to inflect it as a verb, not a noun -- you are telling the
block to be silent). Finally, since this is the purest form of
syntactic sugar, I cannot fathom any parsing, interpreting or other
complications that would arise.
I appreciate any feedback, including frank statements that you'd
rather not trifle with such nonsense.
~Oren
[1] http://www.google.com/codesearch?q=except%3A\spass&hl=en
[2] http://www.google.com/codesearch?hl=en&lr=&q=silence+lang%3Apy
So, why exactly should the language /encourage/ unnecessary error
silencing? (which is what the proposed sugar would do)
> I appreciate any feedback
Applicable rules of The Zen[1] that the proposal arguably violates:
*Special cases aren't special enough to break the rules.
*There should be one-- and preferably only one --obvious way to do it.
Cheers,
Chris
--
http://blog.rebertia.com
I wonder if you're intending that silence: denotes a block in which all
exceptions would be ignored. And that any calls made from there that
threw exceptions would also be ignored.
If so, it's a bad idea. Only if you could qualify it to a particular
exception list might it be reasonable. As it stands, it's just as bad
as the bare try/except that you were already given. Do you really want
to ignore syntax errors, skip bad data, and ignore missing files, and
generally plow down whatever execution path happens to result?
Just my opinion.
DaveA
I would be against this, because "except: pass" is a terrible code
smell. Usage of exceptions can roughly be divided into two areas:
1. Cases where you do know quite well what might go wrong
2. Cases where all kind of stuff might go wrong, including things you
perhaps did not think of, and want to deal with all of them
In the first case, you should not use a blanket "except", but a more
specific one, catching only the specific error or errors you are
dealing with.
In the second case, a blanket except might well be correct, but in
that case, you should not want to pass over the error silently.
Usually you will want to notify the user that an error has occurred.
Even if that is not the case, you want to make some kind of logging of
the error, so that you have the chance of finding it if it is indeed
an unexpected (and therefore undoubtedly also unintended) error.
Doing a pass over an exception is not a bad thing in itself, but one
should only do it when one _knows_ that it is the right action to
take. If you have a general exception, you don't know _what_ has gone
wrong, so you sure as hell cannot be sure about what's the best action
to take. Doing nothing might well be your best guess, but even in that
case I want to know that your program has been guessing when I use it.
--
André Engels, andre...@gmail.com
The general response to "except: pass" from the Old Ones on the
python list (and those younger ones who tend to prescribe good
style) is a fairly immediate "don't use bare excepts". So
endorsing this "silence" syntax would be tantamount to condoning
bare excepts. I'm not sure you'll find much support.
http://www.google.com/search?q=site%3Amail.python.org+%22bare+excepts%22
(I've had problems with Google finding all posts to c.l.p on
m.p.o recently, so this may only be a recent representative sample)
-tkc
Given that python HATE bare-except (and `pass`-block bare except is even
worse) and given python's idiosyncrasies "There should be one-- and
preferably only one --obvious way to do it", "Errors should never pass
silently"; the chance for `silence` keyword is precisely zero.
> I appreciate any feedback, including frank statements that you'd
> rather not trifle with such nonsense.
There are lots of reason why bare-except is bad, one being is that it
makes it way too easy to ignore errors that you don't actually want to
silence; and given that bare-excepts would prevent Ctrl+C (Interrupt)
from working. Sorry, but IMHO we shouldn't make syntax sugar for bad
practices.
Bare excepts are a very bad idea. And you want syntactic sugar for them?
Aargh! :-)
> There are lots of reason why bare-except is bad, one being is that it
> makes it way too easy to ignore errors that you don't actually want to
> silence; and given that bare-excepts would prevent Ctrl+C (Interrupt)
> from working. Sorry, but IMHO we shouldn't make syntax sugar for bad
> practices.
Right. Another way I've seen this expressed is “It should be easy to
do the right thing, and awkward to do the wrong thing”.
--
\ “Everyone is entitled to their own opinions, but they are not |
`\ entitled to their own facts.” —US Senator Pat Moynihan |
_o__) |
Ben Finney
> Howdy all, longtime appreciative user, first time mailer-inner.
> I'm wondering if there is any support (tepid better than none) for the
> following syntactic sugar:
> silence:
> ........ block
> ------------------------->
> try:
> ........block
> except:
> ........pass
-100
This catches Control-C interrupts, sys.exit(), subtle typos in the code,
and sundry other errors that actually you *did* want to know about.
Silence isn't so much golden as pyritic.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Hopefully not.
> The logic here is that there are a ton of "except: pass" statements[1]
> floating around in code that do not need to be there.
s/do not need to be/NEVER should have been at first/