-
-
Notifications
You must be signed in to change notification settings - Fork 34.1k
gh-141984: Reword and reorganize the first part of Atoms docs #144117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Blaise Pabon <blaise@gmail.com>
| occurrence) may obtain the same object or a different object with the same | ||
| value. | ||
|
|
||
| .. admonition:: CPython implementation detail |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not .. impl-detail::?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...?
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
StanFromIreland
left a comment
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| implementation for built-in numeric types works as described in | |
| implementation for built-in numeric types works as described in the |
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/