[Python-Dev] Breaking undocumented API
Nick Coghlan
ncoghlan at gmail.com
Wed Nov 17 14:30:25 CET 2010
On Wed, Nov 17, 2010 at 11:21 PM, Fred Drake <fdrake at acm.org> wrote:
> 2010/11/17 Michael Foord <fuzzyman at voidspace.org.uk>:
>> So -1 on splitting Python development style guide into multiple documents.
>
> I don't think that the publicness or API stability promises of the
> standard library are part of a style guide. They're an essential part
> of the library documentation. They aren't a guide for 3rd-party code,
> and are specific to the standard library.
>
> If we can't come up with something reasonable for the standard
> library, we *certainly* shouldn't be making recommendations on the
> matter for 3rd party code. If we do come up with something
> reasonable, we can recommend it to others later (once field-proven),
> and without duplication. (Possibly by referring to the standard
> library documentation, and possibly by refactoring. That's not
> important until we have something, though.)
Would it make people happier if we left PEP 7 and PEP 8 alone, and put
the clarification of what constitutes a "public API" into PEP 5
instead? PEP 5 currently the deprecation policy for language
constructs, it would be easy enough to extend it to all public APIs.
The library documentation is *not* the right place for quibbling about
what constitutes a public API when using other means than the library
documentation to find APIs to call.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list