gh-138284 : urllib.parse.parse_qsl now raises ValueError if illegal characters is passed, according to RFC 3986
urllib.parse.parse_qsl earlier it was accepting the illegal characters as well.
Proof (that I reproduce) :
Closes issue : #138284
Proof (after fixing error):
I added the test for it as well.
Test for urlparse only :
All tests:
- [x] Passes all tests
- Issue: gh-138284
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.
If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.
If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.
Please add a NEWS entry, and this does break existing code.
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.
If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.
@StanFromIreland I have added your suggestion. Can you please review it again. Thank You
I have requested the expert for this module.
Suggestion: Squash your commits below to have a single commit.
Please do not, it confuses gh making it difficult to review. They will be squashed when merged anyway.
Hello @Davda-James any updates on the suggestion provided? If you are occupied then can I take your changes further?
@shloktech have changed according to suggestions but it was left upto @orsenthil if we needed this or not .. if acknowledgement comes from him, will then update docs and test coverage
Hello @orsenthil can you please help with review and approval? Feel free to let us know if you have any questions.
CC: @StanFromIreland / @picnixz / @Davda-James
Hello @orsenthil,
Gentle Reminder 3: Could you please review the comments shared above and help us with your feedback and approval for the proposed changes related to #138284?
This request has been pending review on your end for nearly 2 months, so it would be great if we could expedite the process. Please let us know if you need any additional information or clarification.
CC: @StanFromIreland / @picnixz / @Davda-James Tagging top contributors: @gvanrossum / @vstinner / @benjaminp
Thank you for your time and support!
Please avoid tagging unrelated users. Usually, we ask for experts to chime in and we have a huge PR backlog.
This request has been pending review on your end for nearly 2 months, so it would be great if we could expedite the process.
Some PRs sit for even longer and the words "expedite the process" won't make the process faster. I would also suggest not to use LLM-generated answers. Finally, as it was said, this PR is still not in a mergeable state as docs and tests are lacking (on purpose, so it's fine for now).
@serhiy-storchaka What do you think about this one? I personally don't consider this as a bug because we explicitly say:
The urlsplit() and urlparse() APIs do not perform validation of inputs. They may not raise errors on inputs that other applications consider invalid. They may also succeed on some inputs that might not be considered URLs elsewhere. Their purpose is for practical functionality rather than purity.
I'm inclined to say "well, why not" since this check is only performed if strict is true but OTOH, it could open a can of worms where users would want more and more checks.