GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||
GeezerVison is showing github.com — gh-95913: Copyedit, link & format Typing Features section in 3.11 What's New by CAM-Gerlach · Pull Request #96097 · python/cpython Conversation
|
| m3: Movie = {"year": 2022} # error (missing required field title) | ||
| m1: Movie = {"title": "Black Panther", "year": 2018} # OK | ||
| m2: Movie = {"title": "Star Wars"} # OK (year is not required) | ||
| m3: Movie = {"year": 2022} # ERROR (missing required field title) |
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation for the ALLCAPS change here? It looks like shouting to me.
("OK" is fine but I'm not a fan of "ERROR".)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
It is intended to draw emphasis to the key contrast these examples are included to illustrate—the first and second are valid, while the third is invalid and produces an error. Also, "OK" is of course the correct, canonical capitalization of "OK", while it is "Error" is ALLCAPSed given the particular importance and best practice of prominently marking bad code as such.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
"ERROR" still seems ugly and unnecessary to me; I don't really see the need for a change here.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
It also goes against the prevailing style in the typing docs — there are several # error comments, but none of them are ALLCAPS: https://docs.python.org/3/library/typing.html
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Personally, I value clarity and explicitness over subjective aesthetic preference, given a stated rationale. Also, I'm not sure how relevant the conventions of the typing stdlib doc are here, given it is a separate document from this one, and those particular choices may or may not have a clear, thought-out rationale.
But what do others think? @ezio-melotti @JelleZijlstra ?
If an all-caps ERROR is simply too objectionable, we can at least give it proper case
| m3: Movie = {"year": 2022} # ERROR (missing required field title) | |
| m3: Movie = {"year": 2022} # Error (missing required field title) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
@AlexWaygood what about if we go with @ezio-melotti 's suggestion and not ALLCAPSing Error, like this?
| m3: Movie = {"year": 2022} # ERROR (missing required field title) | |
| m3: Movie = {"year": 2022} # Error (title is required, but missing) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
@AlexWaygood what about if we go with @ezio-melotti 's suggestion and not ALLCAPSing Error, like this?
Sounds good to me.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
For inline comments like these I tend to use all lowercase and no full stops at the end, so even ok and error would be fine with me.
Same, I don't add a period at the end either for inline or single-line comments...but I notice you do use period for titles (and commit summary lines), which slightly confuses me :) (To note, I do start them with a capital letter, which follows the examples in PEP 8 and avoids looking (IMO) sloppy—though that latter point is personal aesthetic preference)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
FWIW, in this general document, I'd appreciate a subtle indication that this is a typing error -- not a SyntaxError or runtime exception. Perhaps Wrong, in whatever case you prefer.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
That's a great point—to be more specific, we could say something like Type check error or Incompatible type
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I still don't really think there's a good rationale for changing # error to # ERROR, but that's a minor nit :)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Merging, the minor nit can be resolved later. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thanks @CAM-Gerlach for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…11 What's New (pythonGH-96097) Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Alex Waygood <[email protected]> (cherry picked from commit 558768f) Co-authored-by: C.A.M. Gerlach <[email protected]>
|
GH-96934 is a backport of this pull request to the 3.11 branch. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…t's New (GH-96097) Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Alex Waygood <[email protected]> (cherry picked from commit 558768f) Co-authored-by: C.A.M. Gerlach <[email protected]>
…t's New (GH-96097) Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Alex Waygood <[email protected]> (cherry picked from commit 558768f) Co-authored-by: C.A.M. Gerlach <[email protected]>
…t's New (GH-96097) Co-authored-by: Ezio Melotti <[email protected]> Co-authored-by: Alex Waygood <[email protected]> (cherry picked from commit 558768f) Co-authored-by: C.A.M. Gerlach <[email protected]>
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.