PEP 835: Address Discourse feedback and align better with typing spec#5027
PEP 835: Address Discourse feedback and align better with typing spec#5027till-varoquaux wants to merge 2 commits into
Conversation
Key changes: - Structure & Formatting: Reordered all sections to strictly comply with the PEP 1 template. Added a mandatory "Security Implications" section. - Terminology & Spec Alignment: Consolidated terminology to provide clear definitions for the concepts used throughout the PEP (Type Expression, Type Metadata, Non-Typing Annotation, Symbol Decorator) and align better with the typing spec. - Forward References: Clarified that `Format.TYPE` supports `None @Metadata` structurally, eliminating the need to modify `NoneType.__matmul__`. Consequently, removed the "Supporting None" open issue. - Rejected Ideas: Expanded the section to include "Alternative Syntaxes" (e.g. `<@`, soft keywords, brackets), noting their rejection due to lack of consensus. Moved the `__rmatmul__` rejection out of the Specification section. - Future Work: Added extensive examples of how the syntax might map to future Symbol Decorators, and added a JSR 308-inspired proposal for PEP 746 target-based constraints using intersection types (`&`).
Documentation build overview
|
|
@JelleZijlstra thanks for the feedback. Removed @erictraut: I borrowed your process-of-elimination logic for the "Why the @ Operator?" section. Thank you so much. |
b644885 to
9ef1934
Compare
ilevkivskyi
left a comment
There was a problem hiding this comment.
LG, thanks, I have few random comments.
|
|
||
| Using ``@`` might confuse users expecting matrix multiplication. Within a type | ||
| expression, Python intentionally reuses standard operators (like ``|`` and | ||
| ``[]``) with typing-specific semantics. |
There was a problem hiding this comment.
I am not sure what this rejected idea means.
| Writing ``address: (str | None) @Field(...)`` adds verbosity due to the lack | ||
| of native symbol decorators. Frameworks co-opt ``Annotated`` to configure | ||
| fields, even though the developer's intent is to configure the ``address`` | ||
| field, not the ``str | None`` type. |
There was a problem hiding this comment.
This section feels unresolved. You should add some kind of conclusion here.
| expression, Python intentionally reuses standard operators (like ``|`` and | ||
| ``[]``) with typing-specific semantics. | ||
|
|
||
| Format.TYPE and ``@`` in type hints |
There was a problem hiding this comment.
This section title is unclear as well. It should be formulated as a very short description of a thing being rejected.
9ef1934 to
b444c9e
Compare
b444c9e to
a417416
Compare
Key changes:
Format.TYPEsupportsNone @Metadatastructurally, eliminating the need to modifyNoneType.__matmul__. Consequently, removed the "Supporting None" open issue.<@, soft keywords, brackets), noting their rejection due to lack of consensus. Moved the__rmatmul__rejection out of the Specification section.&).PEP 123: Summary of changes)