Nick Coghlan <ncogh...@gmail.com> added the comment: > The former sounds like fixing the bug, the latter like removing > functionality. So yes, I prefer the former...
The reason I'm reluctant is that it makes for a fundamental change in behaviour between the use of an @contextmanager definition as a context manager and as a decorator. The former would continue to be a one-shot operation, just like opening a file and implicitly closing it at the end. The latter (if fixed) would need to implicitly recreate the context manager on each call to the function, creating the illusion of the context manager being reusable. The difference in underlying behaviour bothers me a great deal, as does the effective creation of a "context decorator" protocol that is the moral equivalent of the implicit context manager __with__ method that received barely any interest when I posted it on python-ideas. Given that it is impossible for anyone to be using this feature at this stage (since we just added it and it doesn't actually work in practice), I would prefer to simply acknowledge that I screwed up in failing to completely think through the implications of adding it and ditch it completely. If someone really wants this functionality to work, then they can do it right and write the implicit context manager PEP. (Note that ContextDecorator itself is fine, as long as the context manager is reusable. It's the fact that ContextGenerator *isn't* reusable that causes problems). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11647> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
