the death of lecter

Alex Martelli aleaxit at
Mon Sep 11 21:43:12 CEST 2000

"Michal Wallace" <sabren at> wrote in message
news:Pine.BSF.4.10.10009111130480.20577-100000 at
>    * 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:
                print "foo"
                print "errors"
            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.


More information about the Python-list mailing list