From: Alex Martelli [mailto:aleax@aleax.it]
> On Sunday 02 February 2003 10:49 pm, Paul Moore wrote: ...
>
> > which I've been referring to as acquire/release. The only
> > property-like cases I'm aware of are properties themselves.
>
> Wouldn't classmethods and staticmethods also be able to exploit (in
> a simpler way) the syntax/semantics used for properties? That's the
> impression I had.
Classmethods and staticmethods are already covered by the patch to allow
def myfn(f) [staticmethod]:
...
I don't see any value in looking further than this, as I think that this
syntax is clean, extensible, and understandable.
> I do like your "unified proposal" for the "with" case (I have no idea
> if "with" is the pluperfectly right sugar for this, btw -- no biggie
> anyway, i think).
>
> > the exception should be propogated. The problem is that I'm not sure
> > what is the best way for an __except__ method to signal that it
> > caught the exception.
>
> Maybe the return value of __except__ should be evaluated in a boolean
> context encoding this? False -> exception not caught, True -> caught
> ...
>
> So, an __except__ without return statements (implicitly returning
> None, thus false) would be a clean-up thingy that does no catching
> (but e.g. just rollbacks some DB transactions or whatever), for
> example -- a "return True" would explicitly signal the exception was
> caught -- etc.
Yes, that sounds exactly right - thanks! This was one of the options I
was thinking about, but I hadn't convinced myself that an __except__
with no return did something which felt right. But your explanation
convinces me.
Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4