[Python-Dev] Coding practice for context managers (original) (raw)

R. David Murray rdmurray at bitdance.com
Mon Oct 21 13:26:50 CEST 2013

On Mon, 21 Oct 2013 07:21:11 -0400, "R. David Murray" <rdmurray at bitdance.com> wrote:

On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore <p.f.moore at gmail.com> wrote: > On 21 October 2013 11:59, R. David Murray <rdmurray at bitdance.com> wrote: > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman <ethan at stoneleaf.us> wrote: > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > >> > > >> > In short, I recommend that efforts be directed at improving help() rather than limiting introspection by way of less clean coding practices. > >> > >> +1 > > > > I'm also +1 on improving help instead of using wrapper classes. > > Agreed. A wrapper function whose purpose is solely to tidy up help > seems like a bad idea in general. > > I'm somewhat more sympathetic to Nick's point that the name the user > types should be all-lowercase and a class would be mixed case, but on > that I think it's actually the naming convention that should change > (name classes/functions based on usage, not implementation). The rule > to me is that changing the underlying implementation shouldn't affect > the user interface.

+1. I've run into this tension between the naming convention and wanting to change the underlying API before, and I think the naming convention gets in the way.

Grr. The underlying implementation.

This specifically came up in the case of whether a factory function was a function or a class. A class is a perfectly good factory function, but API-wise is often seems more natural to document it and name it as a function.

--David

More information about the Python-Dev mailing list