MultipartUpload.Part specifies `part_number` as `str` but should be `int`
Closed this issue · 10 comments
Describe the bug
The type is incorrect
To Reproduce
Call Part
on a MultipartUpload
object with a str
instead of an int
Actual output
Invalid type for parameter PartNumber, value: 0, type: <class 'str'>, valid types: <class 'int'>
Expected output
None because the call is successful
Hello! Thank you for the report.
According to boto3 docs, it should be a string: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/service-resource/MultipartUploadPart.html
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/multipartuploadpart/part_number.html
Aren't you just pointing at the code that has the bug in it?
If you look at the documentation for the API itself, it clearly states that it's "a positive integer between 1 and 10,000"
This is a bug in botocore
shapes. I can accept int | str
. Could you please cross-check that the call is successfulboth with str
and int
values?
Found this boto3
issue that is 100% related: boto/boto3#3501
I am going to add a fix for it.
Fixed in the latest mypy_boto3_builder
release. Also, I released mypy-boto3-s3 1.34.160
with the fix included. Please update and let me know if it works as it should.
This is a bug in
botocore
shapes. I can acceptint | str
. Could you please cross-check that the call is successfulboth withstr
andint
values?
It doesn't work with str
so was it changed to be just int
in the release you did?
According to boto/boto3#3501, it does not work with str
.
Yes, my testing confirms that as well, but you proposed it being int | str
in the comment that I quoted and I wanted to make sure that that wasn't the solution and that it was now just int
. Is that what was done?
Yes, you can check the latest release notes for a short explanation. Potentially it affects other services, but I did not verify how many typed identifiers exist in botocore shapes.
Doh! Didn't think of that. I looked at the diff and wasn't sure but the description sounds correct.
Thanks for the quick turnaround on this!