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

Thu Dec 15 17:00:21 CET 2011

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.

Thanks to Andre for his practical data.  Getting real data like that fits
in two situations:

   1. In a production situation where you need speed now, and you know your
   environment.
   2. Teaching about the *idea* of timing and optimization (knowing that
   what is optimal now, may not be in the future)

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

On Thu, Dec 15, 2011 at 7:05 AM, Laura Creighton <lac at openend.se> wrote:

> In a message of Wed, 14 Dec 2011 23:01:54 PST, kirby urner writes:
> >I happen to agree with your sentiments.
> >
> >I still think  mytally [ mykey ] =3D 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.
>
> We're going to have to disagree about this one being 'just right' then.
>
> >> The problem is that, after a certain stage in language development, you
> >> get beyond the point where every new feature you add is completely
> positi
> >ve.
> >> 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 ahe
> >ad?
> >
> >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?
>
> Yes, this is pretty much my position. I don't think, in general,
> we can improve Python by making any more changes to the core language,
> and each change adds to the cognitive load we need to take on to
> learn the language.  It used to take good employees 6 months to go
> from 'this is my first Python program' to being good Python programmers,
> and now it takes them longer.  I'm not sure how much longer, or how
> we could go about measuring this, but I'd like to.
>
> But, again, I'm in favour of putting Software Transactional Memory into
> PyPy, and this will demand a syntax change.  If the benefits of using
> STM happen -- we get to use our multi-cores for free -- then I think
> this would be a good candidate for a core language change.  I hope that
> we will end up with the construct:
>
> with atomic:
>    <these operations are executed atomically>
>
> see:
> http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html
> for more details.
>
> This is what I consider a new, very high level construct that would make
> Python a more high-level language than it is today.  I'm vastly more
> sympathetic towards language changes like this, as oppsed to language
> changes of the 'grow a few more methods here and there'.  I think that
> large new syntactical changes have to face much harder scrutiny, as to
> whether or not they are beneficial.  But it's hard to argue against
> adding this method, and that one in particular.  Each of them adds only a
> tiny bit of cognitive load.  Thus I worry about the boiled frog effect.
>
> The other thing I worry about is that many people, for whatever
> reason, like making syntactic changes to programming languages.  I'm
> guilty of this vice myself.  I think that everybody should design
> computer languages, for fun, because there is a real joy in this.
> (Just don't inflict the rest of the world with your shiny new
> languages unless you really think that you have something new to
> offer.)  What is worse, from this perspective, is that good number of
> people are only interested in programming in languages where a good
> number of syntax changes are happening all the time.  If the changes
> stop happening, they abandon ship and move to another, more rapidly
> evolving place.  Thus, even if we could reach consensus that Python
> was more or less finished, there will still be pressure to keep making
> changes (which some people would persist in calling evolving) out of
> fear that we will loose these people.
>
> I think that the nicest thing about the moratorium was how few people left
> because of it, and that, when it was over there wasn't a huge surge in
> pent up demand as people began agitating for hundreds of changes, those
> they had been sitting on since the ban began.  This says to me that a
> good number of changes are things that people really could and did live
> without.  Or maybe those who only want to be using cutting edge languages
> have jumped ship a long time ago, and are programming in Clojure or
> something, and we just didn't notice.
>
> >Wouldn't it be refreshing to have Python not evolve just so a lot more
> >people could say they'd contributed a PEP?
>
> I don't follow this.  I'm opposed to making changes in the language so
> that more people can say that their PEPs were accepted, but I don't
> think that this is what you were proposing either.
>
> >If you really can't live with the limitation of Python being how it
> >is, start a new language.
>
> Yes.  This is what Dennis Ritchie used to say when people proposed changes
> to C after a certain amount of time.  I think this was very good for C.
>
> >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 "co
> >re"
> >such that these would be self-labeling as "dialects" or "mutant forms".
>
> The architectural problem that looms here is 'when should XXX be part
> of the core language' vs 'XXX should be part of a library'.  And our
> past says 'for reasons of performance, we need to grow the core
> library, even if for other reasons we would prefer not to do so'.  I
> think that this assumption is now being undermined by the new
> multi-core architectures we have, but only time will tell.
>
> >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).
>
> Oh, I deeply sympathise with this problem. Suggestions of ways to
> automate this process are _also_ very welcome here.  I'm getting
> seriously involved in automated testing of students these days,
> ways that students from remote locations can submit work online to
> be evaluated.  (There are no grades here.).  I had hoped that the ability
> to cut and paste would reduce my workload.  It hasn't worked out that
> way.  Possibly this is because I end up using every minute I save to
> say something that I would otherwise have skipped, regretfully, with the
> notion that it was too bad that I didn't have time to mention ...
>
> >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.
>
> Well, that's really all I wanted to hear. :-)  If you can stand up to your
> own self-scrutiny, which I know is competant, then you probably aren't
> promoting shallow cleverness.  But we are going to have to disagree about
> the
> readability of the get method.
>
> Laura
>
> >
> >Kirby
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>

-- 
Dr. Andrew N. Harrington
  Computer Science Department
  Loyola University Chicago
Lakeshore office in the Math Department: 205 Loyola Hall
http://www.cs.luc.edu/~anh
Phone: 773-915-7999
Fax:    312-915-7998
aharrin at luc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20111215/4d1301c4/attachment-0001.html>