homepage

Logged In: YES 
user_id=261020
So, you (Neil) agree with my three numbered action points
below? You repeat my suggestion that we document this as if
it were a new suggestion; did you read my comment?
Sigh, sorry for being a little grumpy about this, but it's
hard to "do no worse" for a project if that project doesn't
seem itself to be very sure what it considers "worse":
While I must say I *agree* with you that such practices are
not good, if I as somebody apparently unusually inclined to
heavy use of underscores (even in most of my module names,
in library code) actually thought, however foolishly, that I
was *following stdlib conventions* by using *fewer*
underscores (for reasons I'll try to refrain from debating
further here), it does indeed seem pretty clear we're in
need of explicit documentation on this! So your advice to
"do no worse" is a little annoying at this point... :-)
OK, so, what should get documented, specifically? And where
should documentation for module authors go?
a). Stdlib module authors should always use underscores for
non-public module globals.
b). Don't know about this one: should non-legacy stdlib
modules (viz, those that follow rule a)) define __all__? 
(perhaps a point against doing this is that it may encourage
import * ?).
c). Stdlib packages should use __init__ to export public names.
d). Any discrepancy between __all__ and the API
documentation is a bug.
e). Stdlib users should assume all non- (I guess this should
be go somewhere near the library reference introduction)
Finally, how about my point 2? Should I add underscores to
cookielib module globals I consider non-public (== all
undocumented module globals), or not?
Thanks for the feedback, both of you!