Maybe this would be a good subject for a series of blog posts? There is certainly plenty we have to say based on 20+ years of experience adding stuff to the stdlib (and not adding it).
On Sat, Mar 15, 2014 at 8:55 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 16 March 2014 01:40, Guido van Rossum <gu...@python.org> wrote: > > On Sat, Mar 15, 2014 at 4:02 AM, Giampaolo Rodola' <g.rod...@gmail.com> > > wrote: > > > > This downside of using subclassing as an API should be well known by now > and > > widely warned against. > > I've actually pondered the idea of suggesting we explicitly recommend > the "procedural facade around an object oriented implementation" API > design model in PEP 8, but it's not really a *coding* style guide > issue, and I also haven't been able to come up with a good way of > summarising it. > > That said, should we perhaps start codifying some of these principles > as a "standard library API design guide"? We have a few additional > issues to take into account that most software can ignore, like > "assume that users that already know Python may be using the module > and its documentation to learn a new domain, rather than the other way > around, where a domain expert is just using the module to get things > done". (That was the main driver for the differences between ipaddr > and the accepted ipaddress API). The question about whether or not to > add new boolean flags vs adding new APIs also comes up fairly often. > > At the moment, there's no real way for newcomers to pick up those > principles other than hanging around long enough to see them come up > again. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
