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