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
Improve duck type compatibility of int with float #100268
Comments
Issues like this need to be filed over at https://github.com/python/typing rather than on this issue tracker. Perhaps @JelleZijlstra or @gvanrossum can transfer it over. Having said that, while I agree in principle with many of your points, I doubt we'll be changing this. It's been this way for many years now, and changing it now would be very breaking for a large number of users. |
@AlexWaygood Thank you and sorry for the incorrect filing of this issue. I agree that this has been part of Python since the beginning of support of typing. It would be a big BC break (affecting also all my projects). I was thinking about sending a PR to mypy that would "fix" this using an optional switch. But then I realised that because of how the PEP484 is phrased, it would be incorrect to disallow assigning int to float. Maybe there's a way it could be rephrased so that it would allow for such option in Mypy? In current state, my PR would be almost certainly rejected. |
float
should not allow value of type int.
float
should not allow value of type int
While your premise it true, a float is not an int. I don't think this has a chance. The PEP 484 decision was intentional and pragmatic. It reflects what is done in a lot of real world code (functions that accept floats also accept ints). And subsequent to the PEP being approved, the decision proved to be useful in practice. To change the decision would require broad discussion and buy in and perhaps another PEP. If you want to pursue that route, I recommend starting a discussion on the forums. Just expect that it will be an uphill battle. The original decisions wasn't made lightly. |
I agree with what was said above, but a few more thoughts:
|
I'd be happy to see this added, and I agree it would lessen some of the pain here. Another precedent is the way that >>> x = 5
>>> x.real
5
>>> x.imag
0 |
Int is supposed to be duck type compatible with float. So yes, it should have all (instance) methods of float. |
Yes, |
float
should not allow value of type int
I think there's consensus that This is brought up somewhat regularly on mypy's issue tracker. I think there's a little bit of an XY complaint happening here in that the actual behaviour that static typing users get confused by is OP also provides a |
@hauntsaninja Do you have bandwidth to make a corresponding PR for adding |
JakubTesarek commentedDec 15, 2022
•
edited by bedevere-bot
Feature or enhancement
Function arguments and variables annotated with
float
should not allow value of typeint.
Pitch
PEP484 suggested that
when an argument is annotated as having type float, an argument of type int is acceptable;
. This allows this kind of typing to be valid:x: float = 2
But
int
is not subtype offloat
and doesn't provide the same interface. Float provides methods that are not available inint
:is_integer
fromhex
hex
This violates LSP and is problematic especially with
is_integer
:This method clearly states that it requires
float
and as an author of such code, I would expect thatis_integer
would be available if my typing is correct.There are workarounds (
if int(number) == number:
) but they render theis_integer
useless as it can never be safely used.Just adding the missing methods to
int
(or removing the extra methods fromfloat
) would not be valid solution as there are other problems stemming from the fact thatint
is notfloat
. Eg.:I'm proposing an errata to PEP484 that will remove
when an argument is annotated as having type float, an argument of type int is acceptable;
.Linked PRs
The text was updated successfully, but these errors were encountered: