On Mon, 21 Oct 2013 07:21:11 -0400, "R. David Murray" <rdmur...@bitdance.com> wrote: > On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 21 October 2013 11:59, R. David Murray <rdmur...@bitdance.com> wrote: > > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman <et...@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 _______________________________________________ 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
