Skip to content
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

Refs #27795 -- Removed unnecessary force_bytes() calls in uri_to_iri(). #11710

Merged
merged 1 commit into from Aug 28, 2019
Merged

Conversation

jdufresne
Copy link
Member

The argument to uri_to_iri() is always a string, so can safely call .encode().

The value returned from urllib.parse.quote() is always a string, so can safely call .encode().

https://code.djangoproject.com/ticket/27795

@carltongibson
Copy link
Member

Hmmm. I just a bit worried about this from the docs:

Takes a URI in ASCII bytes ...

Is the argument always a string? Rather than bytes? (It seems so in the tests but...)

What do you think?

@jdufresne
Copy link
Member Author

I believe the docs are incorrect and should be changed to something like:

Takes a URI of type str composed of ASCII ...

No where internally (code and tests) does Django pass bytes to this function.

WDYT?

…i().

The value returned from urllib.parse.quote() is always a string, so can
safely call .encode().
@jdufresne
Copy link
Member Author

Hmm, maybe you're right that it is better to be safe here. I've limited the change to just the return value of quote() which we know is always str.

@carltongibson
Copy link
Member

Thanks @jdufresne. I’ll have a look at this again in the morning (but seems fine).

I think I agree in principle in the iri case but I bet there’s someone out there passing bytes...

Copy link
Member

@carltongibson carltongibson left a comment

Choose a reason for hiding this comment

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

@carltongibson carltongibson merged commit 1e6b9e2 into django:master Aug 28, 2019
@jdufresne jdufresne deleted the force branch October 24, 2019 23:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants