[Edu-sig] Using try / except: any stipulations against routine use?

[Laura Creighton]

In a message of Wed, 14 Dec 2011 18:12:57 PST, kirby urner writes:

>I'll take the opposite view for the sake of argument.
>I think returning a default if a key is not found is one of those
>workaday methods we thank Python for having, so we don't have
>to code up little mini-functions.  If you saw try /except over and
>over and each time it was the same thing:  some dict not having
>a key, so needing to initialize a tally versus incrementing,
>then pretty soon people'd be griping about why Guido didn't
>have the smarts to put something so basic in the dict toolkit.

If you are seeing this over and over, then it is time to reach for
defaultdict, no?  I've found that that often does produce what is for me
more readable code, and has the advantage of being very fast, too.

But your last sentence here bothers me too.  I think that 'smarts' and
'cleverness' are terribly overrated in society today.  It's not that
being stupid is an attractive option.  But often the alternative to
being _clever_ about something is being _wise_ about something.  So
the question, in that case, might not be 'why did Guido not have the
smarts' but 'Was Guido being wise here?'.  Is there a reason why this
sort of thing does not exist?

And, quite often, with questions of this sort you get the answer 'because
there really isn't a need to clutter up the language with XXX' -- and 
you can look up past discussions about features that aren't in Python
and see Guido saying exactly that all the time.

The problem is that, after a certain stage in language development, you
get beyond the point where every new feature you add is completely positive.
Instead, you are stuck with haveing to decide for or against a feature 
that makes expressing 'this sort of problem' easier, and makes for clearer
and more readable code, but at the expense of making it possible to use
these constructs when dealing with 'that sort of problem', where the
result is poorly constructed, harder to read code.  And that is the tradeoff
that is always there.

Blindly trusting that a feature that is in a language should be used whenever
it can be used, is not wise.  But if we have a language for grown-ups, which
relies on self-discipline, and indeed assumes that programmers have the
wisdom to use Python well, then, well, there is nothing for it but as
educators to try to promote wisdom.

Suggestions on better ways to do this are most welcome.  So far, being
somewhat disapproving of cleverness, and downright hostile towards
gratuitous cleverness is about the best I can do.  As well as sending
assignments back with the note -- refactor for redability -- which at
least gets people thinking beyond 'how to solve this'.

Laura