On Fri, Apr 27, 2012 at 5:21 AM, Guido van Rossum <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com