Message201119
| Author |
ncoghlan |
| Recipients |
barry, ethan.furman, ncoghlan, paul.moore, pitrou, r.david.murray |
| Date |
2013年10月24日.12:33:41 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1382618022.05.0.14943750784.issue19331@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Documenting it as a callable is a pretty strong hint that it shouldn't be subclassed, but I agree my wording above is wrong. Next attempt (leaving out the mention of leading underscores, since that is covered elsewhere):
=================
Class Names
-----------
Class names should normally use the CapWords convention.
The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.
Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.
=================
I initially had the following appended to the second paragraph: "... , and instances expose no public mutable attributes or instance methods (but may provide read-only data attributes, alternative constructors and appropriate special methods)".
The longer phrasing was designed to explicitly cover itertools.chain.from_iterable, contextlib.redirect_stdio.target and contextlib.suppress.exceptions, but I don't think that level of detail is necessary. |
|