LWN: Comments on "Python identifiers, PEP 8, and consistency"

Python identifiers, PEP 8, and consistency

moxfyre — Thu, 30 Dec 2021 03:45:19 +0000

Puhleez! That should be…

`from __future__ import foolish_consistency`

Python identifiers, PEP 8, and consistency

nye — Mon, 13 Dec 2021 17:19:43 +0000

> At the other extreme of the range, there's PHP to consider :-)

If anything, I would say that PHP is *closer* to the consistent end of the range than Python is, at least if you consider its trajectory. Many of the changes of the last four or five years have been in the direction of improving consistency - sometimes in ways that are similar to those rejected in this Python discussion. Notable are certain cases where "backwards compatibility" was the only defence for otherwise indefensible behaviour, like the weirdness in `implode()` - PHP is definitely more willing than post-3.0 Python to break compatibility in favour of correctness, and consistency is increasingly a part of that.

Granted there are a lot of standard library functions which are simple wrappers around C functions, and in those cases they normally opt for "consistency" with the C function rather than with each other. I personally wish it had fewer of these very shallow wrappers, especially for very widely used libraries like cURL, but I can see the argument.

Python identifiers, PEP 8, and consistency

smitty_one_each — Thu, 02 Dec 2021 13:47:20 +0000

This conversation gets at diminishing returns.

Yeah, `from datetime import datetime` is an eyesore, but it makes an important point about the history of the project.

The newbie marks a turning point when the basics of the language/library are understood, and delving into the 'hysterical raisins' why things are the way they are becomes of interest.

This sort of totalitarian cleanup would be appropriate for a Python4, when the GIL is relaxed, and the Promised Land entered.

Python identifiers, PEP 8, and consistency

buck — Thu, 02 Dec 2021 06:32:43 +0000

Indeed, this got me thinking of the "six" module and wondering whether an "eight" module would allow one to opt into PEP 8-ified naming, but your post has me sold on `import __foolish_consistency__` instead.

Python identifiers, PEP 8, and consistency

NYKevin — Wed, 01 Dec 2021 19:39:09 +0000

It is obvious that there is a tradeoff. The problem is, I've seen people say "there is a tradeoff, therefore the status quo is fine." But that's a non sequitur. The fact that a tradeoff exists has nothing to do with the question of whether or not the status quo is at the right point of that tradeoff. Arguments should be grounded in the specific facts of each individual case, and you almost never see that when people start bringing out the "foolish consistency" quote.

Python identifiers, PEP 8, and consistency

NYKevin — Wed, 01 Dec 2021 19:35:45 +0000

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.

Python identifiers, PEP 8, and consistency

pj — Wed, 01 Dec 2021 17:24:19 +0000

I feel like people who want that level of consistency could make a `pep8ed` module that would be just aliases.

from pep8ed.datetime import DateTime, TimeDelta

they could even write code to monkeypatch such aliases in so all they'd have to do is something like:

from pep8er import pep8ify
import datetime

pep8ify(datetime)

now = datetime.DateTime.now()

...once this kind of thing is done, it arguably could go live with stdlib. It'd be cute to be able to

import __foolish_consistency__

to enable such a feature :)

Python identifiers, PEP 8, and consistency

jmaa — Wed, 01 Dec 2021 17:04:49 +0000

Remember when Tony Hoare called the null pointer a billion dollar mistake?

In the spirit of quantifying mistakes, let's try a Fermat-style equation for how much money and time might be wasted in migrating codebases to use new consistent identifiers, in a scenario where the original names are deprecated. I pulled these numbers from my ass, but they sound plausible:

1 000 000 000 lines of actively maintained Python code
0.001 incidence ratio of deprecation
1 minute per incidence
40$ hourly programmer wage

So that's around 16666 wasted work hours, and $666666 down the drain. This only counts the direct migration work, not all of the political drama and dread related to backwards-incompatible version upgrades, or the costs incurred by botched migrations.

Python identifiers, PEP 8, and consistency

martin.langhoff — Wed, 01 Dec 2021 14:43:53 +0000

_Too much_ consistency can asphyxiate. Python has generally struck a good balance at the consistent and tidy end of the spectrum.

That's one of the points where having a lead everyone trusts to make calls in these gray zones is key.

At the other extreme of the range, there's PHP to consider :-)

Python identifiers, PEP 8, and consistency

epa — Wed, 01 Dec 2021 07:44:39 +0000

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

NYKevin — Wed, 01 Dec 2021 02:45:21 +0000

> Angelico, along with others in the thread, pointed to the first section of PEP 8, which is titled "A Foolish Consistency is the Hobgoblin of Little Minds" (from the Ralph Waldo Emerson quote). That section makes it clear that the PEP is meant as a guide; consistency is most important at the function and module level, with project-level consistency being next in line. Any of those is more important than rigidly following the guidelines. As Angelico put it: "When a style guide becomes a boat anchor, it's not doing its job."

I hate this section of the PEP. You can cite it as justification for literally any violation of PEP 8, regardless of whether there's a good reason to violate PEP 8. In my experience, it's very uncommon for people citing this section of the PEP to actually explain the underlying justification for making an exception, even though that very section explicitly states that "Consistency with this style guide is important."

As for consistency within the standard library, or within individual modules... that's a terrible argument. The standard library is wholly inconsistent with itself, and the collections module is an excellent example of this inconsistency. This is actually an argument *in favor* of picking a specific style and standardizing on it, rather than continuing with the status quo. Of course, if you have to pick one style, you should probably pick the PEP 8 style, and so this is not a refutation at all.

Python identifiers, PEP 8, and consistency

iabervon — Tue, 30 Nov 2021 23:25:02 +0000

I think it's useful to use lowercase words for some classes that are generic structure elements, to distinguish them from classes with business logic or application-specific semantics. I think it ought to be TimeDelta to indicate that it's got a particular interpretation but float to indicate that it could be lots of different things from a percentage to a number of seconds. Classes where you can have literals or special syntax for creating them or anything you get out of JSON would be lowercase. If you have a field or variable with a lowercase type, or a function that returns a lowercase type or takes lowercase type arguments, you should think about how your naming, comments, and documentation explain how to interpret the value. If a function returns a CamelCase type, the type's documentation should provide that explanation instead, and the function's documentation can just talk about which one it returns or how it is constructed.

Of course, by this metric, readers of PEP 8 are almost certainly not going to be naming a class that ought to be lowercase, and few packages outside of the standard library's builtins would even do it (exceptions being, perhaps, construct, numpy, and pandas). But I think it would be good (as a retcon) to specify for educational purposes. "If I tell you it's a pathlib.Path, you have some idea what to expect; if I tell you it's a str, you really don't."