Hmm, review link doesn't appear to be available, so just commenting here.


For the "overriding principle" part, you can't switch from a class to a factory function (as that's a backwards incompatible change due to breaking subclassing and isinstance and issubclass checks). The relevant example is going the other way (from a function to relying on a class __new__ or __init__ method instead).

For the addition to the class names section, you can't really jam Paul's wording and mine together like that, as it makes the "this rule" reference ambiguous as to whether it's referring to the previous sentence (intended) or the part before the semi-colon (not intended).

"ABC classes" also doesn't work, since that ends with a repeated "class".

Perhaps:

=================
Class names should normally use the CapWords convention, with classes intended solely for internal use starting with a leading underscore.

This guideline should always be followed for abstract base classes, any other classes where inheritance is encouraged, and classes that are paired with a separate factory function.

In cases where inheritance is not encouraged and it is judged to improve readability at the point of use, the naming convention for callables (lower_case_with_underscores) may be used instead. This is an indication that the type is intended primarily for use "as is", rather than through inheritance (although subclassing is still permitted).

Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.
=================