On 16.07.19 00:32, Barry Warsaw wrote: > On Jul 13, 2019, at 19:09, Raymond Hettinger <raymond.hettin...@gmail.com> > wrote: >> >> In some modules, we've been careful to use both __all__ and to use an >> underscore prefix to indicate private variables and helper functions >> (collections and random for example). IMO, when a module has shown that >> care, future maintainers should stick with that practice. >> >> The calendar module is an example of where that care was taken for many >> years and then a recent patch went against that practice. This came to my >> attention when an end-user questioned which functions were for internal use >> only and posted their question on Twitter. On the tracker, I then made a >> simple request to restore the module's convention but you seem steadfastly >> resistant to the suggestion. >> >> When we do have evidence of user confusion (as in the case with the calendar >> module), we should just fix it. IMO, it would be an undue burden on the >> user to have to check every method in dir() against the contents of __all__ >> to determine what is public (see below). Also, as a maintainer of the >> module, I would not have found it obvious whether the functions were public >> or not. The non-public functions look just like the public ones. >> >> It's true that the practices across the standard library have historically >> been loose and varied (__all__ wasn't always used and wasn't always kept >> up-to-date, some modules took care with private underscore names and some >> didn't). To me this has mostly worked out fine and didn't require a strict >> rule for all modules everywhere. IMO, there is no need to sweep through the >> library and change long-standing policies on existing modules. > > EIBTI <wink> > > Shameless plug: https://public.readthedocs.io/en/latest/
Hey, what a fantastic little module! I'll hurry and use that a lot! Especially the builtins idea is really great :-P Cheers - Chris p.s.: How about adding @private as well? There are cases where I would like to do the opposite: __all__ = dir() @private _some_private_func_1(...): ... ... @private _some_private_func_n(...): ... not-too-seriously yours - Chris -- Christian Tismer :^) tis...@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : https://github.com/PySide 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HUSOXEYFEBJRMQPC5CSFRB2DDMAARBFV/