Repository navigation
Further improve pow - #6325
Further improve pow#6325
pow#6325Conversation
This comment has been minimized.
This comment has been minimized.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
|
I have no idea how this could be implemented, but it would be great if typeshed could have some kind of regression tests for really thorny cases like assert_revealed_type_equality(pow(Fraction(), 4, None), Fraction)
|
|
Yes, that's #1339. We never got around to actually implementing this, and stubtest and mypy-primer have removed some of the need for it, but it would still be useful. |
|
I love this:
🤣 |
| @overload | ||
| def __init__(self) -> None: ... | ||
|
|
||
| _PositiveInteger = Literal[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25] |
There was a problem hiding this comment.
@AlexWaygood, could you answer a couple of my questions?
- As far I understand the reason to have
_PositiveInteger/_NegativeIntegeris because we can't create "all positive/negative ints" types, right? So by defining a Literal we have at least some type inference for small exponents. - Why did you choose to stop at 25/-20? My only guess now is that it fits in one line according to the formatting rules in typeshed 😅
- Why wasn't 0 exponent included in
_PositiveInteger? I know it wouldn't be strictly "positive" integer then but 2**0 producesintin Python and currently it isAnyaccording to typeshed.
Thank you!
There was a problem hiding this comment.
- Yup, you're quite correct! There's no way (not yet, anyway) of expressing "positive integer" in a general way, but if you're calling it with literal types, they're likely to be quite small -- and this hack is better than nothing :)
- Yup, once again spot on! I can't remember whether this is exactly the maximum line length black will allow under the settings typeshed has in
pyproject.toml-- but it's close to it, and they're nice round numbers ;) - Um... good catch! No reason at all! Feel free to submit a PR correcting my oversight! 🙂
Too bad emoijs don't work as names, otherwise we could have named this |
With the current stubs, mypy produces this output with the following code snippet:
With the patch that this PR proposes, the output changes to the following:
All other cases that I tested remain unchanged. A more exhaustive test script is attached, as are results of the test script with the current stubs, and with this PR applied:
.txtfile because GitHub won't let me upload a.pyfile, but this is really a Python file. Save it with a.pyextension and run mypy on it to testpow.)The exact command I ran to test this patch was: