Author ncoghlan
Recipients Martin.Teichmann, ncoghlan, serhiy.storchaka
Date 2017-05-17.10:47:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1495018063.18.0.10568591592.issue30306@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-05-17 10:47:43ncoghlansetrecipients: + ncoghlan, serhiy.storchaka, Martin.Teichmann
2017-05-17 10:47:43ncoghlansetmessageid: <1495018063.18.0.10568591592.issue30306@psf.upfronthosting.co.za>
2017-05-17 10:47:43ncoghlanlinkissue30306 messages
2017-05-17 10:47:42ncoghlancreate