On Fri, Apr 27, 2012 at 5:21 AM, Guido van Rossum <guido at python.org> wrote: > Traditionally we've been really lax about this stuff. We should strive > to improve and clarify the exact boundaries of our APIs better. Yeah, I must admit in my own projects these days I habitually mark all module level and class level names with a leading underscore until I make a conscious decision to make them part of the relevant public API. I also do this for any new helper attributes and functions/methods I add to the stdlib. One key catalyst for this was when PJE pointed out a bug years ago in the behaviour of the -m switch that meant I had to introduce a *new* helper function to runpy, because runpy.run_module was public, and I needed to change the signature in a backwards incompatible way to fix the bug (and thus the current runpy._run_module_as_main hook was born). When I use dir() and help() as much as I do to explore unfamiliar APIs, I feel obliged to make sure that introspecting my own code accurately reflects which names are part of the public API and which are just implementation details. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4