Home Original page

the death of lecter

Alex Martelli aleaxit at yahoo.com
Mon Sep 11 15:43:12 EDT 2000 
"Michal Wallace" <sabren at manifestation.com> wrote in message
news:Pine.BSF.4.10.10009111130480.20577-100000 at chi.pair.com...
    [snip]
>    * design by contract (require/ensure/implies)
>      # I still think this would be a good idea!
>      # maybe instead of keywords, they ought to be in
>      # a contract module?

I think a metaclass would be more appropriate, at
least if I understand metaclasses correctly.  You could
already today (I believe) write a metaclass that, when
accessing, say, method foo, also looks for __pre_foo
and __post_foo, and sequences things appropriately
(including perhaps a deepcopy of self to old in the
pre, if necessary to check things in the __post ...).

>    * foreach someSequence: print this
>      # where "this" is a keyword... I think this is dumb now,
>      # but the idea was to have a perl-like anonymous variable

<shudder> -- "if you want Perl, you know where to find it"...?


>    * extended 'try' syntax:
>          try:
>              print 'do something'
>          except:
>              print 'catch errors'
>          finally:
>              print 'clean up' # not allowed in real Python
>
>       # not sure why you'd want to do this, but the fact that you
>       # can't seems kind of sad.. :)

You just have to nest it:
        try:
            try:
                print "foo"
            except:
                print "errors"
        finally:
            print "clean up"

I do agree that an optionally finally-clause after 1 or more except
clauses (and possibly an else clause too) on a try would make for a
nice alternative to this rather cumbersome nested syntax where except
(& maybe else) and finally are mutually exclusive.

"Why you'd want to do this" seems rather obvious -- catch errors
AND also guarantee some finalization.


Alex
More information about the Python-list mailing list