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

kirby urner kirby.urner at gmail.com
Thu Dec 15 17:25:08 CET 2011


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

<< snip >>

> We're going to have to disagree about this one being 'just right' then.
>

That's OK.  Another attitude / realization I tried to get across in
the top thread of my post is:  schools of thought exist within the
Python community.

"you'll find some polarization among Pythonistas about whether
this is good style" I said.  "Polarization" is a good word because
we know you can't have left without right, up without down --
they define one another.

To take another probably less controversial example, I believe
PEP8 or one of those encourages always triple quoting docstrings.

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

I'm guessing few of us here always triple quote our docstrings.

>
> with atomic:
>    <these operations are executed atomically>
>
> see: http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.html
> for more details.
>

This whole discussion was enlightening / educational, re additions
to core Python.  I'm tempted to change the subject line and do
a branch on this.

A proposal consistent with a permanent moratorium would be:
yes, many dialects of Python, variants of Core, include the
"with atomic" syntax, and you'll want one of those if doing
multi-core programming -- unless of course you want to try
PythonX by the team at Y, still experimental but....  etc.

In other words, just because Core Python is innocent of the
multi-core environment, doesn't mean we can't have five
Not-Core Pythons that deal with it intelligently.

Core Python becomes frozen, a kind of fossil, but there's
just the one of them, the superclass.  Then you have subclasses
of Python-the-language that inherit and hearken back, but
don't claim themselves to be Core anymore.  No more fights.
Just Diversity.

You might see where I'm going with this:  a version of
Python with all keywords in Farsi for example.  It's actually
Core but with this one change.  Rather than say we're
running it through a translator, we're saying we have
at least 300 new Pythons by the end of 2015, each in
a different unicode language (when it comes to keywords).

Of course many would decry this availability of multi-
language Pythons and say it detracts from the universal
readability of the One ASCII / English Core Version.
But that's jumping the gun.  Maybe only a tiny ethnic
subculture of Farsi speakers use the Farsi one and so
on, which the super-vast majority continue with the
English core.  So what?  I'm just saying:  it'd be useful
to have the idea of "dialects" or "versions" well
developed on many axes, not just one-core / multi-core.

Kirby


More information about the Edu-sig mailing list