Skip to content

Conversation

@encukou
Copy link
Member

@encukou encukou commented Jan 21, 2026

This freshens up Syntax Notes, Atoms introduction, Built-in constants, and Literals.
Identifiers and enclosed forms are left for a future PR.

References to mixed arithmetic are changed to link to the stdtypes documentation. In later passes I want to move the runtime semantics there; for now I want to make the “When a description of an arithmetic operator” note in the intro more correct.


📚 Documentation preview 📚: https://cpython-previews--144117.org.readthedocs.build/

encukou and others added 2 commits January 21, 2026 16:08
occurrence) may obtain the same object or a different object with the same
value.

.. admonition:: CPython implementation detail
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not .. impl-detail::?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to see where .. impl-detail:: ends, which is crucial in this case. The paragraph on Template strings logically follows this information, but is not an implementation detail any more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, that makes sense. I wonder why .. impl-detail:: doesn’t create an admonition but rather just bold text...?

encukou and others added 2 commits February 9, 2026 11:16
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Copy link
Member

@StanFromIreland StanFromIreland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two little notes but otherwise LGTM :-)

:ref:`grammar notation <notation>` will be used to describe syntax,
not lexical analysis.

When (one alternative of) a syntax rule has the form
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When (one alternative of) a syntax rule has the form
When (one alternative of) a syntax rule has the form:

* if either argument is a complex or a floating-point number, the other is converted to a floating-point number;

* otherwise, both must be integers and no conversion is necessary.
implementation for built-in numeric types works as described in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
implementation for built-in numeric types works as described in
implementation for built-in numeric types works as described in the

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

Labels

awaiting core review docs Documentation in the Doc dir skip news

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants