On Thu, Nov 11, 2021 at 9:33 PM Ethan Furman <ethan@stoneleaf.us> wrote:
I think what Paul is referring to is that according to PEP 8:
- functions: Function names should be lowercase, with words separated by underscores as necessary to improve readability.
- types: Class names should normally use the CapWords convention.
And, of course:
- Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation.
So, given those three items, should `str` be `str` because it is used often as a function, or should it be `Str` because it is often subclassed?
-- ~Ethan~
I understand why this idea got shut down faster than centrifuge-launched satellite, but I enjoyed reading the resulting thread and I learned a lot. Especially this idea which I have previously missed: - Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation. Is there a standard idiom-- perhaps using a type-hint-- to signal to the IDE/linter that my user-defined class is intended to be used as a function/factory, and not as a type (even though it is in fact a type)? Unaware of the "reflected usage" guidelines, I have done this in the past: class _Spam: ... # todo def spam(*args): return _Spam(*args) I haven't done this often; usually it hasn't made much sense to bury the implementation into a private class like this. Most often it has been because I don't want to commit a class interface as the long term API; want to leave room to change my mind later. Seems like if there were a standard idiom for telling the linter "this class is really just kind of a factory, don't complain about the lowercase", it might be kind of nice. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler