Skip to content

improve types for RequestData - #2404

Closed
adriangb wants to merge 10 commits into
encode:masterfrom
adriangb:improve-types-1
Closed

adriangb wants to merge 10 commits into
encode:masterfrom
adriangb:improve-types-1

Conversation

@adriangb

@adriangb adriangb commented Oct 11, 2022 •

Copy link
Copy Markdown
Contributor

Comment thread httpx/_multipart.py Resolved
Comment thread httpx/_multipart.py
yield DataField(name=name, value=item)
for name, data_value in data.items():
if data_value is None or isinstance(
data_value, (*PRIMITIVE_DATA_TYPES, bytes)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DataField accepts bytes in addition to the other "primitive types". I'm not sure where else PrimitiveTypes is being used but we might want to consider expanding everywhere to accept bytes instead of just here.

Comment thread httpx/_multipart.py
Comment on lines +219 to +220
for name, file_value in file_items:
yield FileField(name=name, value=file_value)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mypy complains about sharing the variable value for both data and file types

Comment thread httpx/_content.py
Comment on lines -142 to +147
if isinstance(value, (list, tuple)):
plain_data.extend([(key, primitive_value_to_str(item)) for item in value])
else:
if value is None or isinstance(value, PRIMITIVE_DATA_TYPES):
plain_data.append((key, primitive_value_to_str(value)))
else:
plain_data.extend([(key, primitive_value_to_str(item)) for item in value])

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flipping these checks lets us handle any sequence instead of special casing List and Tuple.

@adriangb

Copy link
Copy Markdown
Contributor Author

@tomchristie how would you feel about running pyright in CI so we can use it for informational purposes, maybe using it’s typing score as a rough metric for “is this PR improving things for users” without any sort of enforcement?

@lovelydinosaur

lovelydinosaur commented Oct 12, 2022 •

Copy link
Copy Markdown
Member

I'd suggest that if we're going to start making type changes like this and #2266, then we do so with a more precise approach.

Removing TypeError checks.

Personally I'm probably against this, but more importantly let's discuss that as a separate issue.

Stricter type checking with mypy.

I'd be okay with pull requests that resolve mypy strict type checking issues. I'd suggest that pull requests include the mypy httpx --strict output before and after the change, and only make changes that resolve the output. PRs should either only deal with a single module at a time, or should only deal with a single mypy error class at a time.

Enforced stricter type checking with mypy.

I don't think we need to consider turning on mypy --strict in our CI at the moment. If we're getting close to full compliance, then it'd be worth looking at enabling that.

Stricter type checking with pyright.

I'd prefer we avoid adding a node dependancy to our CI. I'd be interested in seeing what issues pyright currently indicates, and determining if mypy --strict covers the same set of cases or not.

Comment thread httpx/_multipart.py
):
yield DataField(name=name, value=data_value)
elif isinstance(data_value, typing.Sequence):
for item in data_value:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving the type checks to this function lets us handle any sequence

@adriangb

Copy link
Copy Markdown
Contributor Author

@tomchristie I requested re-review since I removed the removal (so restored?) the runtime type checks. This is still touching multiple modules but it is dealing only with a single type (RequestData).

I think that the lack of changes to the tests (besides adding a check for a case that would have previously been a false positive) are a good indication that this is not changing any runtime behavior despite the internal refactoring.

@lovelydinosaur lovelydinosaur added the refactor Issues and PRs related to code refactoring label Jan 4, 2023
@lovelydinosaur

Copy link
Copy Markdown
Member

Closing as stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactor Issues and PRs related to code refactoring

Development

Successfully merging this pull request may close these issues.

2 participants