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

Fix all codec issues #145

Merged
merged 10 commits into from
Jun 19, 2023
Merged

Fix all codec issues #145

merged 10 commits into from
Jun 19, 2023

Conversation

jribbens
Copy link
Collaborator

Closes #128, closes #134, closes #138, closes PR #144 (by incorporating it).

The attempt to use 'idna' as the codec name has been removed, as Python searches through the registered codecs in the order that they were registered, and the 'encodings' module (which provides the system 'idna') is imported as part of the interpreter start-up, so it will always win.

core.encode / core.decode have been changed so that instead of saying "if the input type is bytes, call s.decode" they say "if the input type is not str, call str(s)". This is important, not least because when you call b'foo'.decode('idna2008'), Python actually passes the codec decode function a memoryview object!

The codec tests file has been considerably expanded so that it will detect all the issues that were fixed, and so that all the codec entry points are tested.

elliotwutingfeng and others added 10 commits June 19, 2023 00:48
It complains about runTest() returning anything other than None.
Registering 'idna' does nothing, as the standard library version will
always take precedence.

Renamed codec.getregentry() to codec.search_function() to avoid
confusion - getregentry is copied from the encodings.* standard library
modules, but those functions in those modules are *not* codec search
functions (hence why they don't have or check a 'name' argument).
Also add a test to ensure the codec we are using genuinely is our codec
and not the standard library's version!
Convert the input to a string before processing it.
@kjd
Copy link
Owner

kjd commented Jun 19, 2023

Thanks Jon!

@jribbens
Copy link
Collaborator Author

I'm not sure what is up with the mypy tests on Python 3.5 and 3.6, as far as I can tell from the output, the diagnostic they are raising is simply flat-out wrong.

@kjd kjd merged commit 701288b into kjd:master Jun 19, 2023
13 of 15 checks passed
kjd added a commit that referenced this pull request Jun 19, 2023
In PR #145, the tests are giving abberant results which appears to be
a mypy issue, not a legitimate issue with the types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants