
On Thu, 11 Nov 2021 at 17:13, Carl Meyer <carl@oddbird.net> wrote:
I'm also -1 on churning the stdlib in search of a global consistency that PEP 8 itself disavows, but this particular argument against it doesn't make sense:
On Thu, Nov 11, 2021 at 9:14 AM Paul Moore <p.f.moore@gmail.com> wrote:
To examine some specific cases, lists are a type, but list(...) is a function for constructing lists. The function-style usage is far more common than the use of list as a type name (possibly depending on how much of a static typing advocate you are...). So "list" should be lower case by that logic, and therefore according to PEP 8. And str() is a function for getting the string representation of an object as well as being a type - so should it be "str" or "Str"? That's at best a judgement call (usage is probably more evenly divided in this case), but PEP 8 supports both choices. Or to put it another way, "uniform" casing is a myth, if you read PEP 8 properly.
Any type can be called to construct an instance of that type. If I define a class Foo, I create an instance of Foo by calling `Foo(...)`. `list` and `str` are no different; I can create an instance of the type by calling it. This doesn't mean they are "both a type and a function" in some unusual way, it just means that we always call types in order to construct instances of them.
I understand that. However, PEP 8 states "Names that are visible to the user as public parts of the API should follow conventions that reflect *usage* rather than *implementation*." (My emphasis) I quoted this, but you cut that part of my post. My point here is that how you interpret "usage" is far from clear - I'm sure that a lot of people would teach str(...) as a function that creates a string representation of an object, deferring the detail that it's actually a type, and you can call a type to create objects of that type until later. So would a newcomer necessarily know (or even need to know) that str is a type, not a function? There's also the case of changing implementation between a class and a factory function - surely that should not require a compatibility-breaking name change? The key is that it's fairly easy to argue "reasonable doubt" here - PEP 8 is intended to be applied with a certain level of judgement, not as a set of absolute rules. But yes, I didn't make my point particularly clearly, I apologise. Paul