-
Notifications
You must be signed in to change notification settings - Fork 242
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
Stricter type checking for Python integers and floats #1554
Conversation
This is a breaking change and should probably get a CHANGELOG entry, if it were accepted. |
d8fe29f
to
61634a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love the deletion of all the coerce()
calls, but I'm not sure about how to implement the check.
return value | ||
|
||
@classmethod | ||
def write(cls, value, buf): | ||
cls.writeChecked(value, buf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not understanding the need for a separate writeChecked
method. What if this stayed as just write()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cls.writeChecked(value, buf) | |
cls.writeChecked(cls.check(value), buf) |
It's missing a cls.check
call around the value. Seems like I'm missing some tests…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added that cls.check
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I understand now. What about write_unchecked
instead? That follows the Rust meaning of "unchecked" and also follows PEP 8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about
write_unchecked
instead?
write_unchecked
/writeUnchecked
sounds good.
and also follows PEP 8.
I also prefer that naming style. I tried to fit in though; most of the file is using camelCase
, e.g. all of RustBuffer
's methods: allocWithBuilder
, consumeWithStream
, … Should I still change it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to writeUnchecked
for now. If you want to have it as write_unchecked
instead, please say so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree what you have now is more consistent with the existing style, even though pep-8 does recommend otherwise.
6fbd1e9
to
39ee669
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine to me
try: | ||
value = value.__index__() | ||
except Exception: | ||
raise TypeError("'{}' object cannot be interpreted as an integer".format(type(value).__name__)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an aside, I'd probably be in favour of declaring we only work with 3.6 and up (even 3.7 TBH, seeing 3.6 is getting no security updates) which would mean f-strings could be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
side-note: Glean supports 3.6 and that's also the minimum for mozilla-central.
return value | ||
|
||
@classmethod | ||
def write(cls, value, buf): | ||
cls.writeChecked(value, buf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree what you have now is more consistent with the existing style, even though pep-8 does recommend otherwise.
What's still missing to get this merged? @bendk |
I'll give this a look tomorrow |
TBH I think it's ready and the only reason I didn't merge it is because Ben explicitly requested changes and I didn't want to speak for whether he thought the updates were ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good. I'll check with Ben.
@heinrich5991 In the meantime can you add the changelog entry?
39ee669
to
2d4e890
Compare
Done. EDIT: Now also conflicts resolved. EDIT2: Now also rebase mistake fixed. |
2d4e890
to
b0a8cf2
Compare
Kotlin and Swift don't need it either way because they're statically typed. By moving it directly to the lowering/writing, it avoids a bunch of no-ops when no coercing is actually needed, e.g. when recursively coercing lists.
The error messages mirror the ones used in Python itself. E.g.: ```python >>> chr(1.0) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'float' object cannot be interpreted as an integer >>> class A: ... def __index__(self): ... return 1.0 ... >>> chr(A()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: __index__ returned non-int (type float) ``` and ```python >>> math.sqrt("1") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: must be real number, not str >>> class A: ... def __float__(self): ... return "1" ... >>> math.sqrt(A()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: A.__float__ returned non-float (type str) ``` Fixes mozilla#1544. Also add some tests checking the stricter type checking plus a few floating point roundtrip tests.
b0a8cf2
to
0f44aef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I agree it's better to match the current naming style. We can tackle the PEP-8 update in a different PR.
Thank you, @heinrich5991! |
The error messages mirror the ones used in Python itself. E.g.:
and
Fixes #1544.
Also add some tests checking the stricter type checking plus a few floating point roundtrip tests.