Python identifiers, PEP 8, and consistency

Posted Dec 1, 2021 7:44 UTC (Wed) by epa (subscriber, #39769)
In reply to: Python identifiers, PEP 8, and consistency by iabervon
Parent article: Python identifiers, PEP 8, and consistency

I like the approach taken by Haskell, where types and constructors must start with a capital letter, and ordinary functions must not.

In Python, one answer might be to make the language case insensitive. Wait, hear me out… suppose you can declare particular source files or classes to be case insensitive, so callers can use any case. The library code can then be made consistent. An automatic linter or cleaner will convert code to the canonical form used in the library. If you do that cleanup, you can then go back to strict case matching. Or you might choose to keep working in case-insensitive mode and get warnings, rather than hard errors, on mismatches. Effectively making it a code style issue rather than some non-negotiable semantic question, which it doesn’t need to be.

That doesn’t do much for studlyCaps versus underscores, I admit. I guess if you must have aliases, they should be declared specially so that linter tools (and the compiler’s own diagnostics) can help the programmer. They should not just be a bunch of wrapper functions.

Python identifiers, PEP 8, and consistency

Posted Dec 1, 2021 19:35 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Having spent a fair amount of time working in a case-insensitive Pascal-like language (hello, Skyrim modding!), this is actually a lot less painful than it sounds.* However, your capitalization will get irregular if you don't have a standard style and some kind of automated enforcement mechanism. If your language supports variable shadowing (which Papyrus does not, but Python obviously does), then it might be more painful because you will have a larger set of variables potentially "in scope" and there is greater potential for collisions, which the compiler will not warn you about.

> That doesn’t do much for studlyCaps versus underscores, I admit. I guess if you must have aliases, they should be declared specially so that linter tools (and the compiler’s own diagnostics) can help the programmer. They should not just be a bunch of wrapper functions.

You don't need wrapper functions in Python. Python functions and classes are first-class objects, so you can just do this:

def original_name(args...): ...

alias = original_name

If a linter is unable to figure that out, it needs to be redesigned from the ground up.

* Except for the case-insensitive strings. Those are terrible.