Message293848
Re-reading my previous comment, I now realise it wasn't particularly clear.
To be more explicit, I agree with Serhiy that since the internals of how @contextmanager works are a private API, it makes sense to switch to a two-class design that doesn't rely on the _recreate_cm() mechanism at all, and instead relies on overriding `__call__()` for the decorator use case.
At runtime, the end result is pretty similar to your current implementation, but the split into two classes more clearly separates the base "use a generator as a context manager" functionality from the "implicitly wrap a generator around a functional call" feature.
It makes sense to do that, since the current self.__class__ based design stems from the time when I was considering making this a public API (and hence needed to account for inheritance), and I didn't go back and review it for possible refactoring opportunities when I decided not to do that. |
|
Date |
User |
Action |
Args |
2017-05-17 10:47:43 | ncoghlan | set | recipients:
+ ncoghlan, serhiy.storchaka, Martin.Teichmann |
2017-05-17 10:47:43 | ncoghlan | set | messageid: <1495018063.18.0.10568591592.issue30306@psf.upfronthosting.co.za> |
2017-05-17 10:47:43 | ncoghlan | link | issue30306 messages |
2017-05-17 10:47:42 | ncoghlan | create | |
|