On Thu, 11 Nov 2021 at 17:13, Carl Meyer <c...@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.mo...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2A5OB3Q7GRRPZD2BKBGF2EMAPPJIKBJ6/ Code of Conduct: http://python.org/psf/codeofconduct/
