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

[Laura Creighton]

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