Using try / except: any stipulations against routine use?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

kirby urner-4
On Thu, Dec 15, 2011 at 8:00 AM, Andrew Harrington <[hidden email]> wrote:
> I'm not sure we are clear on the audience here.  I use Python in teaching in
> different situations.   For the newbie course with my Hands-on Python
> Tutorial, the main idea is an intro to creative programming, where many
> students will not get to anything more advanced.  Python is a great vehicle,
> but my emphasis is not on how much of the language an advanced programmer is
> going to use.  The dict get method is not high on my list in the newbie
> class.  In that situation I would be drawn to the    if key in ... syntax.
>

This is along a really steep climb, almost vertical in some sections.

After 16 lessons ending in an ASCII histogram, plotting word lengths
from the Declaration of Independence, they're in the world of
unittest and GUI programming with Tk, SQL.

By the 3rd module (batch of lessons) they're through regular
expressions, command line parsing.

Multi-threading and multi-process spawning come later, towards
the end.

The first Dog class with dog instances in Lesson 14, first module.
@properties in 3rd module, decorators more generally in last.

> Thanks to Andre for his practical data.  Getting real data like that fits in
> two situations:
>
> In a production situation where you need speed now, and you know your
> environment.
> Teaching about the *idea* of timing and optimization (knowing that what is
> optimal now, may not be in the future)
>

timeit module and profile module introduced in fourth batch of
lessons.

I'm working the first three batches only at the moment, on alternate
days.  Been doing it about a year now.

> Neither of these apply if you are just doing an intro to basic logical
> concepts in programming.
>
> When I use Python for my upper level cryptography course, I push way more
> advanced approaches.
>
> Andy
>

We could do a lot more with cryptography and I have lots of code
in the wings that does more with a Tractor class.  That's the
topic of my Standard Lightning Talk for social occasions and
meetups in Pythonia (Python World).

For example the CropCircle subclass of Tractor does a Mandelbrot.

Complex numbers have to do with some of these large number
multiplication algorithms used in RSA.

But I do more with RSA in my Portland pilots.

There's no automated grading at all and you just keep doing
the assignments until you pass them -- can take double digit
numbers of tries in some cases, especially with programs.

What few multiple choice questions there are (very few) are
hand graded.

Our boss went to Russia and realized the students there were
getting a wholly different education that was non-mechanized
and required more thinking on your feet.  This crystallized the
"active learning" or "make math" approach.  He thinks Americans
don't know dick for the most part, are basically faking it 24/7
(I would have to agree, especially when it comes to Washington
DC people and at Harvard).

It's funny to watch students tuck little comments and remarks
in their quizzes at first, wondering if "the machine" will notice.

Yet there is no machine, just a dedicated staff spread out in
different cities, using a shared hub in Illinois (the management
is in Sebastopol, the hardware in Illinois).

Kirby

Erratum

>>> print('''\
If I notice students making assertions like "doctstrings must be
triple quoted" I go:  """no, you *may* consistently always triple
quote even single-lined strings, but unless you have those
embedded linebreaks, "single quoted docstrings" are not an
impossibility -- not a syntax error, not an oxymoron""" (that's
a paraphrase; sounding more literal given I'm not plowing
through at high speed here).'''.replace("literal", "literary"))

If I notice students making assertions like "doctstrings must be
triple quoted" I go:  """no, you *may* consistently always triple
quote even single-lined strings, but unless you have those
embedded linebreaks, "single quoted docstrings" are not an
impossibility -- not a syntax error, not an oxymoron""" (that's
a paraphrase; sounding more literary given I'm not plowing
through at high speed here).
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

Christian Mascher
In reply to this post by Bert Freudenberg

>> On the other hand,
>>      res_dict[ext] = res_dict.get(ext, 0) + 1
>>
> Isn't this at least as readable, and conceptually simpler?
>
>     if ext in res_dict:
>         res_dict[ext] += 1
>     else:
>         res_dict[ext] = 1
>


I haven't done much coding in Python lately. And I found this much more
readable than the .get method which I forgot about. I positively didn't
understand the oneliner just by reading it over and over again.

Of course I could easily have opened idle and looked up the .get method
online (or looked in a manual).

The really good thing about Python is that so much of the core language
doesn't surprise you. One is able to write code which is understandable
even to people with very little experience or to yourself after not
coding in Python for years. Nobody has to write such clear-cut code all
the time, but at least it is possible with very little effort.

Christian
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

kirby urner-4
On Thu, Dec 15, 2011 at 10:18 AM, Christian Mascher
<[hidden email]> wrote:

>
>>> On the other hand,
>>>     res_dict[ext] = res_dict.get(ext, 0) + 1
>>>
>> Isn't this at least as readable, and conceptually simpler?
>>
>>    if ext in res_dict:
>>        res_dict[ext] += 1
>>    else:         res_dict[ext] = 1
>>
>
>
> I haven't done much coding in Python lately. And I found this much more
> readable than the .get method which I forgot about. I positively didn't
> understand the oneliner just by reading it over and over again.
>

I might try something like this to make it clearer.

I can cut and paste such code snippets from my Replies
archive (another way to save time -- I edit from a pool
and splice in what's custom).

This goes off the common cartoon convention of a
prisoner putting one stroke on a wall for each day
in prison.  Here we use a string of "bars" (apropos).

>>> def strokes(prisoner, days=1):
        cells[prisoner] = cells.get( prisoner, "") + "|"*days

       
>>> cells = {}
>>> strokes("Mandela")
>>> cells
{'Mandela': '|'}
>>> strokes("Aung San Suu Kyi",10)
>>> cells
{'Aung San Suu Kyi': '||||||||||', 'Mandela': '|'}
>>> strokes("Mandela")
>>> strokes("Mandela")
>>> cells
{'Aung San Suu Kyi': '||||||||||', 'Mandela': '|||'}

What's also important is cells is global and need not be declared
global in strokes for this to work.  That's a stumbling block in
Lesson 12 or one of those, I forget which exactly, and is a
subtle aspect of Python:  you can poke items into a global
dict from a more local scope, just not rebind the name to some
other object.

> Of course I could easily have opened idle and looked up the .get method
> online (or looked in a manual).
>

Our you could wake up in the morning and have
a bunch of fresh feedback from a faithful mentor,
who points stuff out that passes for "accepted
holes" out there, but you could use to your advantage
in a job interview.  You know about dict.get, wow.
Hey, it's a competitive market out there.

I think we should have a whole thread on defaultdict
though.  I think we should also expose students to
importing django not to run a web service at first,
but to gain access to some low-level goodies like the
ordered dict.  Treat zope the same way -- just
something to import and "make math" with (interactive
console in CR or Eclipse in the current working
versions).

> The really good thing about Python is that so much of the core language
> doesn't surprise you. One is able to write code which is understandable even
> to people with very little experience or to yourself after not coding in
> Python for years. Nobody has to write such clear-cut code all the time, but
> at least it is possible with very little effort.
>

Yes, which is why Python is favored by the scientific
community.  It's powerful, thanks to libraries like numpy
and visual, comes with pyMol and sciPy and like that,
and you don't have to turn yourself into some compsci
geek to use it, just hack away and it makes sense, does
what you expect, fits your brain.

Python is great because now the physics team doesn't
have to sit around waiting for some back office "programming
team" to do some slow-poking away off camera.  "No, we
can do it ourselves!" -- the sense Python inspires.

I'm all for this.  As a long time math reformer, I've taken
the line that forcing Texas Instruments calculators down
the throats of K-12ers while denying them access to
free open source options such as Python, is malpractice
in the first degree and all student loans should be forgiven,
based on what was done to you people, and how you're
unemployable now, living in a tent someplace.  Dang.
Wouldn't it have been nice if the teachers had listened.

Kirby


> Christian
>
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

Carl Cerecke-4
In reply to this post by Christian Mascher
I know I'm late to this discussion, but I tend to use something like:

if ext not in res_dict:
    res_dict[ext] = 0

res_dict[ext] += 1

Cheers,
Carl.

On 16 December 2011 07:18, Christian Mascher <[hidden email]> wrote:

On the other hand,
    res_dict[ext] = res_dict.get(ext, 0) + 1

Isn't this at least as readable, and conceptually simpler?

   if ext in res_dict:
       res_dict[ext] += 1
   else:         res_dict[ext] = 1



I haven't done much coding in Python lately. And I found this much more readable than the .get method which I forgot about. I positively didn't understand the oneliner just by reading it over and over again.

Of course I could easily have opened idle and looked up the .get method online (or looked in a manual).

The really good thing about Python is that so much of the core language doesn't surprise you. One is able to write code which is understandable even to people with very little experience or to yourself after not coding in Python for years. Nobody has to write such clear-cut code all the time, but at least it is possible with very little effort.

Christian

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

Vern Ceder-3
On Mon, Dec 19, 2011 at 4:19 PM, Carl Cerecke <[hidden email]> wrote:
I know I'm late to this discussion, but I tend to use something like:

if ext not in res_dict:
    res_dict[ext] = 0

res_dict[ext] += 1

Cheers,
Carl.


Hi Carl,

Actually, I often do that as well. I'm not sure it's the most efficient, but it does make quite clear what you are doing.

Cheers,
Vern

 
On 16 December 2011 07:18, Christian Mascher <[hidden email]> wrote:

On the other hand,
    res_dict[ext] = res_dict.get(ext, 0) + 1

Isn't this at least as readable, and conceptually simpler?

   if ext in res_dict:
       res_dict[ext] += 1
   else:         res_dict[ext] = 1



I haven't done much coding in Python lately. And I found this much more readable than the .get method which I forgot about. I positively didn't understand the oneliner just by reading it over and over again.

Of course I could easily have opened idle and looked up the .get method online (or looked in a manual).

The really good thing about Python is that so much of the core language doesn't surprise you. One is able to write code which is understandable even to people with very little experience or to yourself after not coding in Python for years. Nobody has to write such clear-cut code all the time, but at least it is possible with very little effort.

Christian

_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig


_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig




--
Vern Ceder
[hidden email], [hidden email]
The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

kirby urner-4
In reply to this post by Carl Cerecke-4
>
> if ext not in res_dict:
>     res_dict[ext] = 0
>
> res_dict[ext] += 1
>
> Cheers,
> Carl.

Truth be told, I do that too a lot.

After being shown all the options, let the programmer choose.

However, in a learning situation, it's about showing these options,
including with the dict.get method.

These patterns need not be visited in a vaccuum, i.e. it's quite often
that one needs a default returned (and not an error message) if such
and such is the case, a pre-existing value otherwise.

This pattern is not confined to dicts of course.

What I will correct though, as an example of what I consider a mistake, is like:

for word in wordlist:
    if word == "fox":
        result = True
    else:
        result = False

in place of

result = "fox" in wordlist

Note every alternative weighs equally.  Laura things  thedict [thekey]
= thedict.get( thekey, 0) + 1 is starting to get too fancy / clever /
tricky and detracts from readability (a shared value).

I would agree there are honest disagreements about what's "too clever"
(I think using a builtin method for what it's for should be shown, but
then possibly avoided).

However, coding a loop to go through a list looking for a match,
rather than letting the keyword "in" do the work, strikes me as "poor
Python" that should be tightened up to pass muster.

I don't think an "anything goes" attitude works.  Like in sports, some
moves win more points and when you hire a coach, it's to develop best
practices, not to prove how you're free of all idioms.

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

Vern Ceder-3
On Mon, Dec 19, 2011 at 4:36 PM, kirby urner <[hidden email]> wrote:
However, coding a loop to go through a list looking for a match,
rather than letting the keyword "in" do the work, strikes me as "poor
Python" that should be tightened up to pass muster.

I  absolutely agree on this one...
 
I don't think an "anything goes" attitude works.  Like in sports, some
moves win more points and when you hire a coach, it's to develop best
practices, not to prove how you're free of all idioms.

+1 

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig



--
Vern Ceder
[hidden email], [hidden email]
The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW



_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
Reply | Threaded
Open this post in threaded view
|

Re: Using try / except: any stipulations against routine use?

kirby urner-4
In reply to this post by kirby urner-4
> Note every alternative weighs equally.  Laura things  thedict [thekey]
> = thedict.get( thekey, 0) + 1 is starting to get too fancy / clever /
> tricky and detracts from readability (a shared value).
>

"Not every alternative weighs equally.  Laura thinks..." (fixing errors)...

Quoting from Python scripture, I'm not saying much more than (or much
different from):

"""
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
"""

-- from import this

Kirby
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig
12