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