[Python-Dev] Coding practice for context managers

[R. David Murray]

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