On 21 Oct 2013 22:10, "Antoine Pitrou" <solip...@pitrou.net> wrote: > > Le Mon, 21 Oct 2013 20:46:39 +1000, > Nick Coghlan <ncogh...@gmail.com> a écrit : > > On 21 Oct 2013 12:44, "Raymond Hettinger" > > <raymond.hettin...@gmail.com> wrote: > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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(). > > > > > > 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. > > > > > > In short, I recommend that efforts be directed at improving help() > > > rather > > than limiting introspection by way of less clean coding practices. > > > > 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. > > Let's call them callables instead? > > > 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). > > I don't get why adding public attributes should be related to the > proposed change.
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. Postponing the questions didn't work, so I may as well address them instead. Cheers, Nick. > > Regards > > Antoine. > > > _______________________________________________ > 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/ncoghlan%40gmail.com
_______________________________________________ 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
