Repository navigation
Feature: Expand the style-guide to cover how type names should be written in prose #1821
Description
Describe the enhancement or feature you would like
In order to smooth out stylistic debates about how docs are spelled, the style-guide page should provide guidance about how type-names should be written.
There are various cases in the stdlib in which we refer to a type vs a more general idea (for example: tuple vs "tuples").
There are also cases in which documentation wants to refer to a type as an established idea in the relevant domain rather than the type (for example: "thread-local storage" vs threading.local).
Finally, there are cases where the name of the idea is related to the type name, as in "deque" for collections.deque or "Context Variable" for contextvars.ContextVar.
The style-guide should provide rules for which style to use when writing a type name in prose, so that we avoid and can heal pages like the current contextvars docs, which use ContextVar, "Context Variable", and "context variable".
I propose the following rule as an addition to the style guide below the specific words section:
Type names
When writing the names of types in prose, prefer to write the name of the type exactly as it appears in source, styled as a class reference or an unlinked class. For example, refer to
dictas:class:`dict`or:class:`!dict`.Links should be used according to the
guidance on links <links>.Some type names are commonly understood ideas or nouns outside of Python. For example, "tuples" are a general programming concept, as distinct from the
tupletype. When referring to general ideas, do not style the relevant word as a type.Many types have descriptive names which do not exactly match their type name. For example, "context variables" describes
contextvars.ContextVar, and "partial function" may be used to describe an application offunctools.partial. Use these names only when they serve to clarify the text better than the type name itself would, and put them in lowercase.
Describe alternatives you have considered
Make CPython doc issues and edits without establishing style guide guidance, trying to make things consistent organically over time.
(I think this is unlikely to succeed, but it is possible.)
Additional context
In a recent CPython docs PR, we found that we could not write text that was consistent across different modules because those modules had different styles for referring to relevant classes by name.
Some docs use class names verbatim, as they appear in source, and code-quoted. For example, the new frozendict type is generally written exactly as it is named, styled as a class or link/ref: "frozendict".
Some docs use class names as though they are ordinary nouns. For example, the deque docs refer to "deques", without code quoting or linking.
A small category of docs refer to the class name as though it is a proper noun. At time of writing, I can only find Context Variables as an example of this.
Activity
sirosen commentedon Jun 3, 2026
cc @picnixz
I agree with the desire for consistency you expressed in python/cpython#150325 . I raised it in the docs community, hence this issue, which may interest you.
nedbat commentedon Jun 27, 2026
These seem like good guidelines, but I think will need a little more subtlety. For example, in long prose discussing dictionaries, I'm not sure I'd want every mention of "dict" to be
dict. As you say, sometimes a type name is the same word as a concept. And after enough description of dictionaries (or lists, or bytearrays), they are concepts. It will require judgement to decide when the word means a type and when it means a concept.I definitely agree that "Context Variables" shouldn't be capitalized.
sirosen commentedon Jun 28, 2026
As a quick note, the linked PR is currently approved. So if you think we should hold this, it might be good to comment there in order to ensure it doesn't get merged prematurely.
I was operating under the assumption that we can trust people to exercise some measure of judgement in the application of any guidance.
I agree that these guidelines should be flexible, but I'm not sure how to incorporate that into the text itself. I could drop the "only" in the last sentence? That's such a small change, I would find it unsatisfactory as a "solution", although it may still be a good step.