<p dir="ltr"><br>
On 21 Oct 2013 22:10, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> Le Mon, 21 Oct 2013 20:46:39 +1000,<br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> a écrit :<br>
> > On 21 Oct 2013 12:44, "Raymond Hettinger"<br>
> > <<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<br>
> > pass-through factory functions.  The intent is to make the help() look<br>
> > cleaner.  This practice does have downsides however.<br>
> > ><br>
> > > The usual way to detect whether something is usable with a<br>
> > > with-statement<br>
> > is to check the presence of the __enter__ and __exit__ methods.<br>
> > Wrapping the CM in a pass-through function defeats this and other<br>
> > forms of introspection.<br>
> > ><br>
> > > Also, the help() output itself is worse-off.  When you run help on a<br>
> > CM(), you're trying to find-out what happens on entry and what<br>
> > happens on exit.  If those methods had docstrings, the question would<br>
> > be answered directly.   The wrapper (intentionally) hides how it<br>
> > works.<br>
> > ><br>
> > > Since I teach intermediate and advanced python classes to<br>
> > > experienced<br>
> > Python users, I've become more sensitive to problems this practice<br>
> > will create.  Defeating introspection can make the help look nicer,<br>
> > but it isn't a clean coding practice and is something I hope doesn't<br>
> > catch on.<br>
> > ><br>
> > > To the extent there is a problem with the output of help(), I think<br>
> > efforts should be directed at making help() better.   A lot of work<br>
> > needs to be done on that end -- for example abstract base classes<br>
> > also don't look great in help().<br>
> > ><br>
> > > There are a couple of other minor issues as well.  One is that the<br>
> > wrapper function hides the class, making it harder to do type checks<br>
> > such as "isinstance(x, suppress)".  The other issue is that wrappers<br>
> > cause extra jumping around for people who are tracing code through a<br>
> > debugger or using a visualization tool such as pythontutor.   These<br>
> > aren't terribly important issues, but it does support the notion that<br>
> > usually the cleanest code is the best code.<br>
> > ><br>
> > > In short, I recommend that efforts be directed at improving help()<br>
> > > rather<br>
> > than limiting introspection by way of less clean coding practices.<br>
> ><br>
> > That's a fair point, but I *really* dislike exposing implementations<br>
> > that don't match their documentation, and both of these are currently<br>
> > documented as factory functions.<br>
><br>
> Let's call them callables instead?<br>
><br>
> > Exposing the full object oriented API is certainly a  reasonable<br>
> > option, but the docs should be updated accordingly, with suitable<br>
> > public attributes being defined (providing access to the exception<br>
> > tuple for suppress and the target stream for redirect_stdio).<br>
><br>
> I don't get why adding public attributes should be related to the<br>
> proposed change.</p>
<p dir="ltr">Because redirect_stdout previously had undocumented attributes without an underscore prefix, and it was after I had already renamed those and was deciding whether or not to make suppress.exceptions public (and return self from suppress.__enter__) that I had my ill-advised brainwave about postponing dealing with all those questions by hiding the implementation of both of them behind factory functions.</p>

<p dir="ltr">Postponing the questions didn't work, so I may as well address them instead.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<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>