[Python-3000] self-contained exceptions

Phillip J. Eby pje at telecommunity.com
Thu Jan 11 17:52:56 CET 2007


At 08:36 AM 1/11/2007 -0800, Guido van Rossum wrote:
>Let me clarify. I have no desire to prevent tuple assignment in with
>statements. But I do think that the tuples could be limited to plain
>names and other tuples (with similar constraints), and those names
>should all be zapped at the end of the clause, like for except. And we
>don't even have to add an extra try/finally to do so, since with
>already *has* a try/finally...
>
>I'm also curious to hear what people think of similarly limiting the
>syntax of the target in all for-loops -- but WITHOUT the zapping of
>the variable at block end.
>
>I think none of these changes would affect reasonably written code;
>the use cases for using variables that are part of other objects are
>too obscure to care.

Yes, they're obscure.  But the symmetry with assignment is pleasing, 
nonetheless.  It gives me the sense of a "small" language, i.e., one 
without nine jillion special cases.

I've been having to do some Perl hacking this week, and I'm being quite 
thoroughly reminded of the joys of how few special cases Python has.  :)

By comparison, Perl is nothing but special cases, as I keep discovering 
that some symbol combination I thought would work, either doesn't, or does 
something entirely different depending on context.  I keep resorting to 
using "map" and a few other tricks to find some Python-like uniformity and 
composability.

Don't get me wrong, I'm not saying that limiting the assignment targets of 
"with" and "for" will turn Python into Perl.  I'm just saying that not 
having to create different mental categories for their assignment targets 
is pleasant.  In contrast, the "as" in "except" and "import" seems to 
already be a different mental category that occurs seamlessly, whereas 
"for" and "with" seem to bunch with "assignment" in my mind.

But of course all this could just be the peculiarities of my own 
mind.  We'll see what other people think.



More information about the Python-3000 mailing list