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

[kirby urner]

On Wed, Dec 14, 2011 at 7:38 PM, Laura Creighton <lac at openend.se> wrote:

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

I'm happy to see defaultdict enter the picture.  That adds new
grist for the mill.

It's not covered in the lessons I teach from, so it wouldn't be
as apropos, whereas students are much encouraged to
explore the dict object using dir({}) etc.

dict itself is an interesting builtin, being a type name and a
callable, but not a function.  dict( ) is not a function being
called, likewise list( ), str( ), float( ), set( )... int( ).

I'm getting off topic slightly.

Also, I don't think fussing about a few microseconds is
very Pythonic.  If that's really your concern, then C might
be better.  VHLL means we're not anal about micoseconds.
It's an interpreted language for crying out loud.

"Readability" is the value I think we both agree on.

It's more just a matter of where to draw the line.

I'm thinking the dict's get( ) method, like itemsI( ), is
too important to bleep over, especially when you see
students using try: / except: syntax.

Likewise, when introducing print( ), one must look
at the optional keyword arguments, sep=, end= and
file=.  When you see a student laboriously trying to
get around that default space between strings, let
them know they have control.

Here's what I come down to:  at least make sure they
know they have a choice.  If they learn about .get and
still go back to something else, fine.

And that's indeed how I grade.  I never send it back
as "incorrect" if they didn't use .get (if it comes back,
it's for other reasons) and I don't get bent out of shape
if they decide to not incorporate it into their vocabulary,
even after it's been introduced.

At least I did my job in letting them know about it.

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

I happen to agree with your sentiments.

I still think  mytally [ mykey ] = mytally.get ( mykey, 0 )  + 1

is not "too clever".  I think it's rather "just right".  But sure,
use defaultdict instead if you prefer.  Or try / except, even
though it's more verbose.

What'd be a good lesson plan on defaultdict that lets it
strut its stuff.  I think we should incorporate that in one
of our lessons.  Who wants to do unpaid volunteer work. ;-)

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

Which means he thinks dict.get is not clutter.  I feel it's being there
is evidence for my case in this debate.

[ re this being "a debate" and me looking for a shared "value" --
readability -- is likely influenced by my immersing myself in the
teen debate world in Washington / Oregon, and being suitably
and happily impressed much of the time:

http://worldgame.blogspot.com/2011/12/foray-to-washington.html

]


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

Maybe core Python should stop advancing.  Seriously.  Why keep going?

It's a great language, 3 x best in show per LinuxJournal.  Quit while ahead?

Lets have cool libraries but call it quits on adding to core Python.

Is anyone taking that position, just for kicks?

I know about the moratorium that happened for awhile.  Why not make it
permanent?

Wouldn't it be refreshing to have Python not evolve just so a lot more
people could say they'd contributed a PEP?

If you really can't live with the limitation of Python being how it
is, start a new language.

Note:  I am mindful that PyPy provides many more freedoms and think halting the
evolution of core Python would NOT inhibit people from forking off in
all different
directions with *specialized* Pythons that would be for particular
lines of work, i.e.
we could still have many many more Pythons.  Just we're done defining "core"
such that these would be self-labeling as "dialects" or "mutant forms".

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

If someone used:

mytally [ mykey ] = mytally.get ( mykey, 0 )  + 1

instead of one of the two other options presented, I would never
suggest sending it back for readability.  On the contrary, I'd say
it's my job as a Python reader to know this idiom.  This is a core
method of a basic data type.

However, I am persuaded by this thread, and it was also my
position to begin with, that the two alternative ways of doing
this same thing should not be sent back for refactoring either.

I don't do this.  I just present the above idiom and say things
like "many programmers would abbreviate that to this".

I usually quote their code and show the same .get( ) syntax
with the exact same names, which means custom typing
on my part, extra work (I graded 183 items today, many of
them programs, so it's not like I have lots of time to spare).

I don't think I'm going over the line in over-promoting
superficial cleverness, which I agree is not to be encouraged
except in contests / contexts where that's a pre-specified
good / goal.

Kirby