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

bpo-37335: Fix unexpected ASCII aliases in locale coercion tests #14443

Closed
wants to merge 2 commits into from

Conversation

kulikjak
Copy link
Contributor

@kulikjak kulikjak commented Jun 28, 2019

Solaris uses '646' as an alias for ASCII encoding and thus all the locale coercion tests are failing. This patch fixes the problem by using codecs lookup to normalize encoding names and thus prevent these problems.

https://bugs.python.org/issue37335

Copy link
Contributor

@mangrisano mangrisano left a comment

Choose a reason for hiding this comment

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

LGTM.

"print(codecs.lookup(sys.getfilesystemencoding()).name)",
"print(codecs.lookup(sys.stdin.encoding).name + ':' + sys.stdin.errors)",
"print(codecs.lookup(sys.stdout.encoding).name + ':' + sys.stdout.errors)",
"print(codecs.lookup(sys.stderr.encoding).name + ':' + sys.stderr.errors)",
Copy link
Member

Choose a reason for hiding this comment

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

Oh wait, I added _PyUnicode_InitEncodings() in Python 3.8: filesystem and stdio encodings are now always normalized. https://bugs.python.org/issue36775 :

commit 43fc3bb7cf0278735eb0010d7b3043775a120cb5
Author: Victor Stinner <vstinner@redhat.com>
Date:   Thu May 2 11:54:20 2019 -0400

    bpo-36775: Add _PyUnicode_InitEncodings() (GH-13057)
    
    Move get_codec_name() and initfsencoding() from pylifecycle.c to
    unicodeobject.c.
    
    Rename also "init" functions in pylifecycle.c.

So _handle_output_variations() can simply be removed from 3.8, without having to add codecs.lookup().name here.

This change makes sense to Python 3.7. Would you mind to first create a new PR for master, backport it to 3.8, and then retarget this PR to 3.7?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that will be the reason why Python 3.8 no longer has this problem. I will look into it.

Is there a way how to retarget this to 3.7? When we tried it previously, Github tried to backport the whole master into 3.7... Or do I have to create new PR for that as well?

Copy link
Member

Choose a reason for hiding this comment

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

Well, maybe creating a new PR for 3.7 is simpler :-)

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@kulikjak
Copy link
Contributor Author

I opened new other PRs for this change - closing this one.

@kulikjak kulikjak closed this Jun 28, 2019
@kulikjak kulikjak deleted the fix-locale-coercion-alliases branch July 12, 2019 14:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting changes tests Tests in the Lib/test dir
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants