Ben Mather added the comment:
Sorry for slow response. I completely missed your reply.
I was working on a project that used a concurrent.futures thread pool but also
needed to listen to responses from a chip-and-pin card reader.
Payment sessions operated in three phases:
- check with card reader that payment is possible
- save payment to database as if it has happened (always best to undercharge
in the case of an error)
- ask the payment provider to commit the payment
Up until confirmation is received, it is entirely possible to cancel the
session.
Once confirmation is received the session starts trying to commit and you can
only really wait for it to finish and then roll back (or break everything).
This maps pretty well to the interface of future (though with very different
plumbing and with work happening before cancellation stops working) and it made
sense to try to write it so that it could interoperate with futures
representing tasks running on the thread pool.
I tried to add a method which returned a plain concurrent.futures.Future object
but couldn't find a way to hook into the cancel method without introducing
loads of race conditions.
Really it just seemed wrong that I had an object that quacked like a duck but
wasn't a duck because real ducks communicated over a hidden side channel.
The card reader library is open source and mostly functional. The class is in:
https://github.com/bwhmather/python-payment-terminal/blob/develop/payment_terminal/drivers/bbs/payment_session.py
I'm sure there are other places where this sort of interoperability would be
useful.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22729>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
