Remove Type::tuple in favor of TupleType::from_elements#15218
Conversation
sharkdp
requested review from
AlexWaygood,
MichaReiser and
carljm
as code owners
|
|
|
||
|
|
||
| def never() -> Never: | ||
| return never() |
There was a problem hiding this comment.
For a more realistic function that would be reasonably annotated as returning Never, you could do
| return never() | |
| while True: | |
| pass |
But it might be more concise to create the tuple in a function, where the function has a parameter annotated with Never
There was a problem hiding this comment.
For a more realistic function that would be reasonably annotated as returning
Never
What's wrong with my function? I believe it is correctly typed? It's also an infinite loop, just with recursion.
it might be more concise to create the tuple in a function, where the function has a parameter annotated with
Never
I didn't do that on purpose. A function that accepts Never can not be called (as there is no way to produce an element of type Never). So we might later detect its body to be unreachable code?
There was a problem hiding this comment.
For a more realistic function that would be reasonably annotated as returning
NeverWhat's wrong with my function? I believe it is correctly typed?
There's nothing wrong with it at all from a typing perspective! But at runtime, it would obviously cause infinite recursion and not be particularly useful 😆 the more common situation in which a function is annotated as returning Never or NoReturn in my experience is when a function unconditionally raises an exception, or has an infinite loop.
So this is a very minor nitpick, and I certainly don't object if you ignore it and merge your PR as it is! I just think that as a general principle, it's nice if our test snippets emulate realistic Python code as much as possible :-)
There was a problem hiding this comment.
I'm afraid I don't really understand why a function returning Never with an infinite (no op) loop is more realistic / useful than one with infinite recursion?
You mean if someone actually wants to run this, they would prefer an infinite loop because the recursive version would run into "max recursion depth exceeded"? Okay 😄
(Note that this is just a corpus test, not a Markdown test)
I certainly don't object if you ignore it and merge your PR as it is
👍
* main: [`ruff`] Avoid reporting when `ndigits` is possibly negative (`RUF057`) (#15234) Attribute panics to the mdtests that cause them (#15241) Show errors for attempted fixes only when passed `--verbose` (#15237) [`RUF`] Add rule to detect empty literal in deque call (`RUF025`) (#15104) TD003: remove issue code length restriction (#15175) Preserve multiline implicit concatenated strings in docstring positions (#15126) [`pyflakes`] Ignore errors in `@no_type_check` string annotations (`F722`, `F821`) (#15215) style(AIR302): rename removed_airflow_plugin_extension as check_airflow_plugin_extension (#15233) [`pylint`] Re-implement `unreachable` (`PLW0101`) (#10891) refactor(AIR303): move duplicate qualified_name.to_string() to Diagnostic argument (#15220) Misc. clean up to rounding rules (#15231) Avoid syntax error when removing int over multiple lines (#15230) Migrate renovate config (#15228) Remove `Type::tuple` in favor of `TupleType::from_elements` (#15218)
3 participants
Summary
Remove
Type::tuplein favor ofTupleType::from_elements, avoid a few intermediateVectors. Resolves an old review comment.Test Plan
—