<p dir="ltr"><br>
On 21 Oct 2013 12:44, "Raymond Hettinger" <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br>
><br>
> Two of the new context managers in contextlib are now wrapped in pass-through factory functions.  The intent is to make the help() look cleaner.  This practice does have downsides however.<br>
><br>
> The usual way to detect whether something is usable with a with-statement is to check the presence of the __enter__ and __exit__ methods.   Wrapping the CM in a pass-through function defeats this and other forms of introspection.<br>

><br>
> Also, the help() output itself is worse-off.  When you run help on a CM(), you're trying to find-out what happens on entry and what happens on exit.  If those methods had docstrings, the question would be answered directly.   The wrapper (intentionally) hides how it works.<br>

><br>
> Since I teach intermediate and advanced python classes to experienced Python users, I've become more sensitive to problems this practice will create.  Defeating introspection can make the help look nicer, but it isn't a clean coding practice and is something I hope doesn't catch on.<br>

><br>
> To the extent there is a problem with the output of help(), I think efforts should be directed at making help() better.   A lot of work needs to be done on that end -- for example abstract base classes also don't look great in help().<br>

><br>
> There are a couple of other minor issues as well.  One is that the wrapper function hides the class, making it harder to do type checks such as "isinstance(x, suppress)".  The other issue is that wrappers cause extra jumping around for people who are tracing code through a debugger or using a visualization tool such as pythontutor.   These aren't terribly important issues, but it does support the notion that usually the cleanest code is the best code.<br>

><br>
> In short, I recommend that efforts be directed at improving help() rather than limiting introspection by way of less clean coding practices.</p>
<p dir="ltr">That's a fair point, but I *really* dislike exposing implementations that don't match their documentation, and both of these are currently documented as factory functions.</p>
<p dir="ltr">There's also the fact that I prefer the current lower case names, but strongly dislike using lower case names for classes (despite the fact closing was included in the original contextlib with a non PEP 8 compliant class name).</p>

<p dir="ltr">(And yes, I now realise I completely failed to mention either of those points in the comments giving the rationale for the wrapper functions).</p>
<p dir="ltr">Exposing the full object oriented API is certainly a  reasonable option, but the docs should be updated accordingly, with suitable public attributes being defined (providing access to the exception tuple for suppress and the target stream for redirect_stdio).</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> Raymond<br>
><br>
><br>
> -------- current code for suppress() --------<br>
><br>
> class _SuppressExceptions:<br>
>     """Helper for suppress."""<br>
>     def __init__(self, *exceptions):<br>
>         self._exceptions = exceptions<br>
><br>
>     def __enter__(self):<br>
>         pass<br>
><br>
>     def __exit__(self, exctype, excinst, exctb):<br>
>         return exctype is not None and issubclass(exctype, self._exceptions)<br>
><br>
> # Use a wrapper function since we don't care about supporting inheritance<br>
> # and a function gives much cleaner output in help()<br>
> def suppress(*exceptions):<br>
>     """Context manager to suppress specified exceptions<br>
><br>
>     After the exception is suppressed, execution proceeds with the next<br>
>     statement following the with statement.<br>
><br>
>          with suppress(FileNotFoundError):<br>
>              os.remove(somefile)<br>
>          # Execution still resumes here if the file was already removed<br>
>     """<br>
>     return _SuppressExceptions(*exceptions)<br>
><br>
><br>
> -------- current help() output for suppress() --------<br>
><br>
> Help on function suppress in module contextlib:<br>
><br>
> suppress(*exceptions)<br>
>     Context manager to suppress specified exceptions<br>
><br>
>     After the exception is suppressed, execution proceeds with the next<br>
>     statement following the with statement.<br>
><br>
>          with suppress(FileNotFoundError):<br>
>              os.remove(somefile)<br>
>          # Execution still resumes here if the file was already removed<br>
><br>
> -------- current help() output for closing() with does not have a function wrapper --------<br>
><br>
> Help on class closing in module contextlib:<br>
><br>
> class closing(builtins.object)<br>
>  |  Context to automatically close something at the end of a block.<br>
>  |<br>
>  |  Code like this:<br>
>  |<br>
>  |      with closing(<module>.open(<arguments>)) as f:<br>
>  |          <block><br>
>  |<br>
>  |  is equivalent to this:<br>
>  |<br>
>  |      f = <module>.open(<arguments>)<br>
>  |      try:<br>
>  |          <block><br>
>  |      finally:<br>
>  |          f.close()<br>
>  |<br>
>  |  Methods defined here:<br>
>  |<br>
>  |  __enter__(self)<br>
>  |<br>
>  |  __exit__(self, *exc_info)<br>
>  |<br>
>  |  __init__(self, thing)<br>
>  |<br>
>  |  ----------------------------------------------------------------------<br>
>  |  Data descriptors defined here:<br>
>  |<br>
>  |  __dict__<br>
>  |      dictionary for instance variables (if defined)<br>
>  |<br>
>  |  __weakref__<br>
>  |      list of weak references to the object (if defined)<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>