On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote: >By contrast, suppress() and redirect_stdout() are the *first* general >purpose context managers added to contextlib since its incarnation in >Python 2.5 (although there have been many various domain specific >context manager additions elsewhere in the standard library).
There's a fundamental conceptual shift here that's worth exploring more, and which I think was first identified by RDM. Until now, context managers were at their heart (at least IMHO) about managing "resources". A general resource might be an open file, or it might be a database transaction, or even the current working directory. Context managers (as expressed elegantly by the `with` statement) are used to ensure that a resource acquired for some limited operation is - to Python's best ability - "released" at the end of that operation, no matter what happens. E.g. the file is closed even if there's a write error, or the current working directory is restored to its original location. We need only look at the typical @contextmanager use to see the idiom they embody. As shown in the docstring: @contextmanager def acquire(): resource = get_some_resource() try: yield # execute the operation finally: # No matter what happened above... resource.free() redirect_stdout() conforms to this fine tradition, with the resource being sys.stdout. suppress() breaks the mold, which I think is what is breaking people's brains. It isn't about guaranteeing that a resource is restored to its original value after some operation. It's about short circuiting that operation. Just look at the implementation to see this shift in perspective. It doesn't use try/finally, it uses try/except. So it's important to acknowledge that suppress() is charting new territory and it will take some exploration and experimentation to get used to, or maybe even to decide whether it's a good idea. It'll be interesting to see whether this fundamental difference is easily explained, understood, and internalized and that will go a long way to figuring out whether this is a good idea to be expanded on in the future. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com