Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Interest check in some delicious syntactic sugar for "except:pass"

1 view
Skip to first unread message

Oren Elrad

unread,
Mar 3, 2010, 4:27:16 AM3/3/10
to pytho...@python.org
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

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

Chris Rebert

unread,
Mar 3, 2010, 5:25:02 AM3/3/10
to Oren Elrad, pytho...@python.org
On Wed, Mar 3, 2010 at 1:27 AM, Oren Elrad <oren...@gmail.com> wrote:
> 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
>
> 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.

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

[1]: http://www.python.org/dev/peps/pep-0020/

Dave Angel

unread,
Mar 3, 2010, 5:40:56 AM3/3/10
to Oren Elrad, pytho...@python.org
Oren Elrad wrote:
> 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
>
> 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
>
>
I presume you know that there's a feature freeze on for Python. So such
an idea wouldn't be considered for at least a couple of years. But that
shouldn't inhibit such discussions.

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

Andre Engels

unread,
Mar 3, 2010, 6:02:32 AM3/3/10
to Oren Elrad, pytho...@python.org
On Wed, Mar 3, 2010 at 10:27 AM, Oren Elrad <oren...@gmail.com> wrote:
> 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
>
> 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.

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

Tim Chase

unread,
Mar 3, 2010, 7:55:54 AM3/3/10
to Oren Elrad, pytho...@python.org
Oren Elrad wrote:
> I'm wondering if there is any support (tepid better than none) for the
> following syntactic sugar:
>
> silence:
> ........ block
>
> ------------------------->
>
> try:
> ........block
> except:
> ........pass

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

Lie Ryan

unread,
Mar 3, 2010, 8:19:56 AM3/3/10
to
On 03/03/2010 08:27 PM, Oren Elrad wrote:
> 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

>
> 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.

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.

MRAB

unread,
Mar 3, 2010, 10:19:56 AM3/3/10
to pytho...@python.org
Oren Elrad wrote:
> 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
>
> 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.
>

Bare excepts are a very bad idea. And you want syntactic sugar for them?

Aargh! :-)

Ben Finney

unread,
Mar 3, 2010, 5:21:32 PM3/3/10
to
Lie Ryan <lie....@gmail.com> writes:

> 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

Rhodri James

unread,
Mar 3, 2010, 7:11:26 PM3/3/10
to
On Wed, 03 Mar 2010 09:27:16 -0000, Oren Elrad <oren...@gmail.com> wrote:

> 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

Bruno Desthuilliers

unread,
Mar 4, 2010, 6:59:27 AM3/4/10
to
Oren Elrad a �crit :

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

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/

0 new messages