Skip to content
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

Mention use of cast in enum type stub example #1877

Merged
merged 2 commits into from
Oct 30, 2024

Conversation

hauntsaninja
Copy link
Collaborator

In case people gloss over the text, it's good for the example to recommend the thing with the most static information

CAT = ... # Member attribute
DOG = ... # Member attribute
CAT = 1 # Member attribute with known value and type
DOG = cast(str, ...) # Member attribute with unknown value and known type
Copy link
Member

Choose a reason for hiding this comment

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

As a reader, I think I would be confused by the use of str here, given that this appears to be a reimplementation of the above Pet enum. Why not just use int and keep things consistent?

Copy link
Collaborator Author

@hauntsaninja hauntsaninja Oct 29, 2024

Choose a reason for hiding this comment

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

Changed it! I was anchored to some of the conversations we had around using _value_ as a way to spell this (which would work for homogenous types, but not heterogeneous types, as well as being harder to come up with)

docs/spec/enums.rst Outdated Show resolved Hide resolved
Copy link
Member

@carljm carljm left a comment

Choose a reason for hiding this comment

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

Looks fine to me! This is a pretty minor change, but I guess technically any spec change is supposed to go to the whole typing council? Might be good to get at least one more opinion?

@erictraut
Copy link
Collaborator

Looks good to me too.

@JelleZijlstra
Copy link
Member

I think this is fine to merge without the full approval procedure because it doesn't change any normative part of the spec, it just clarifies an example.

@hauntsaninja hauntsaninja merged commit a1d4d07 into python:main Oct 30, 2024
4 checks passed
@hauntsaninja hauntsaninja deleted the enum-example branch October 30, 2024 00:20
carljm added a commit to erictraut/typing that referenced this pull request Jan 9, 2025
* main: (29 commits)
  Updated conformance test results for the latest versions of type chec… (python#1904)
  Add content from typeshed/CONTRIBUTING.md (python#1882)
  Fix markup in generics specification (python#1900)
  Specs clarification: Forbid `ClassVar` and `Final` within `TypedDict` body (python#1890)
  Remove paragraph mentioning minor edits through the mailing list (python#1891)
  Writing Stubs: Add "Overloads and Flags" section (python#1894)
  Fix a typo (python#1893)
  Update conformance tests for recent generics spec change (python#1892)
  Clarify some behavior around user-defined generic classes (python#1879)
  Modernizing guide: Mention TypeGuard/TypeIs (python#1887)
  Tools can perform "some" refactorings (python#1886)
  Mention use of cast in enum type stub example (python#1877)
  Update conformance results after new pyre release (python#1878)
  Add a label for typed dictionaries class-based syntax (python#1873)
  Add missing return type to generic_syntax_infer_variance.py (python#1871)
  Updated conformance results for mypy 1.13 and pyright 1.1.386 (python#1870)
  Modernizing guide: also mention `com2ann` (python#1869)
  Suggest `pyupgrade` or `ruff` for modernizing superseded typing features (python#1868)
  Updated conformance results for pyright 1.1.385. (python#1867)
  Updated conformance results for mypy 1.12. (python#1866)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants