Skip to content

Feature: Expand the style-guide to cover how type names should be written in prose #1821

Description

@sirosen

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 dict as :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 tuple type. 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 of functools.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

  1. sirosen commented on Jun 3, 2026

    @sirosen
    ContributorAuthor

    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.

  2. nedbat commented on Jun 27, 2026

    @nedbat
    Member

    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.

  3. sirosen commented on Jun 28, 2026

    @sirosen
    ContributorAuthor

    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.

    These seem like good guidelines, but I think will need a little more subtlety.

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type-featureAdditions; New content or section needed

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions