From Fedora Project Wiki
Line 110: Line 110:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


A patch will be backported to Fedora's [https://admin.fedoraproject.org/pkgdb/package/rpms/python3/ | Python 3.6] from the upstream [https://www.python.org/dev/peps/pep-0538/ | PEP 538] which target Python 3.7
A patch will be backported to Fedora's [https://admin.fedoraproject.org/pkgdb/package/rpms/python3/ Python 3.6] from the upstream [https://www.python.org/dev/peps/pep-0538/ PEP 538] which target Python 3.7


* Release engineering: No impact with release engineering <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: No impact with release engineering <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->

Revision as of 10:40, 14 February 2017


Change Proposal Name

Summary

Force C.UTF-8 when Python 3 is run under the C locale

Owner

Current status

  • Targeted release: Fedora 26
  • Last updated: 2017-02-14
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

When run under the C locale, Python 3 doesn't work properly on systems where UTF-8 is the correct encoding for interacting with the rest of the system.


This is described in detail by Armin Ronacher in the click documentation: http://click.pocoo.org/5/python3/#python-3-surrogate-handling


This proposed change for the system Python 3 that assumes the current process is misconfigured when it detects that "LC_CTYPE" refers to the "C" locale, and in that case, prints a warnings to stderr and forces the use of the C.UTF-8 locale instead.

To avoid unintended side effects, it *solely* changes the actual python3.6 command line utility - nothing changes for cases where CPython is used as a dynamically linked library.

Behaviour with the patch:

$ LANG=C python -c 'import click; cli = click.command()(lambda:None); cli()'

Python detected LC_CTYPE=C. Setting LC_ALL & LANG to C.UTF-8.

Behaviour without the patch:

$ LANG=C /usr/bin/python3 -c 'import click; cli = click.command()(lambda:None); cli()'

Traceback (most recent call last):

 File "<string>", line 1, in <module>
 File "/home/ncoghlan/.local/lib/python3.5/site-packages/click/core.py", line 716, in __call__
   return self.main(*args, **kwargs)
 File "/home/ncoghlan/.local/lib/python3.5/site-packages/click/core.py", line 675, in main
   _verify_python3_env()
 File "/home/ncoghlan/.local/lib/python3.5/site-packages/click/_unicodefun.py", line 119, in _verify_python3_env
   'mitigation steps.' + extra)

RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Either run this under Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.

This system supports the C.UTF-8 locale which is recommended. You might be able to resolve your issue by exporting the following environment variables:

export LC_ALL=C.UTF-8 export LANG=C.UTF-8

Benefit to Fedora

Scope

  • Proposal owners:

A patch will be backported to Fedora's Python 3.6 from the upstream PEP 538 which target Python 3.7

  • Release engineering: No impact with release engineering

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes