> Why does that matter? calendar.__all__ doesn't export > _localized_name or any of the gimmicks built from it, so it's purely > an internal issue, and the internals never need slices here (granted > that day_name etc are poorly named for module privates -- or perhaps > the __all__ list and the docs are in error). I agree with Skip that these are public enough to make sure common uses will continue to work, despite their current lack of documentation. After all someone did report a bug -- I'm sure that was because they had real code using this which broke, not because they happened to have inspected the code and noticed it was buggy. :-) I have to say that I still think that adding __all__ to every module under the sun was a mistake. --Guido van Rossum (home page: http://www.python.org/~guido/)
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