On 03:42 pm, te...@jon.es wrote:
Hi JP
Thanks for the summary. I agree (and agreed in my first post in this
thread) that the CancelledError should (has to) come all the way back.
I
missed that we were still talking about that.
Was there a conclusion on Glyph's suggestion of using subclasses of
CancelledError? Chris raised the point that there might be many of them
for
a given API. But an API could define a few subclasses, just the most
useful
to start with (if there are any at all), and document them, and later
define some more if need be, etc. That would be backwards consistent
with
processing by Failure.check and try/except on CancelledError - unless
my
Python memory has rotted more than I think. It seems a good path to
providing more info (for APIs that want to). Or is there a problem with
it
that I also missed?
I think technically that would solve the problem. It sounds like a bit
of a nightmare though. But that's what we get for using types to
indicate error conditions, I suppose?
Cancellation is still new, and I don't think many people are using it
yet (how could they, since no one has bothered to write any
documentation for it). I suspect different people probably also have
different ideas about how it *should* be used - and so we've probably
all started to go off in somewhat different directions, which is going
to result in disagreement in what practices are best.
I think the best possible next step here is to actually document what
it's already possible to do with cancellation (I think there are several
non-obvious tricks - mainly in the area of asynchronous cancellation, a
feature not *explicitly* supported by the API, but still possible).
After that, perhaps we'll be able to see what it's *not* possible to do
and then a discussion about how to fill in the gaps in functionality
will be a lot easier to have.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
