Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #100022
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Unicode failure |
| Date | 2015-12-04 18:28 -0500 |
| Message-ID | <mailman.214.1449271745.14615.python-list@python.org> (permalink) |
| References | <20151204130738.76313c43@imp> |
On 12/4/2015 1:07 PM, D'Arcy J.M. Cain wrote:
> I thought that going to Python 3.4 would solve my Unicode issues
Within Python itself, that should be mostly true. As soon as you send
text to a display, the rules of the display device take over.
>
> #! /usr/bin/python3
> # -*- coding: UTF-8 -*-
Redundant, as this is the default for 3.x
> import sys
> print(sys.getdefaultencoding())
> print(u"\N{TRADE MARK SIGN}")
>
> And here is my output.
>
> utf-8
> Traceback (most recent call last):
> File "./g", line 5, in <module>
> print(u"\N{TRADE MARK SIGN}")
> UnicodeEncodeError: 'ascii' codec can't encode character '\u2122' in
> position 0: ordinal not in range(128)
Tk widgets, and hence IDLE windows, will print any character from \u0000
to \uffff without raising, even if the result is blank or . Higher
codepoints fail, but allowing the entire BMP is better than any Windows
codepage.
--
Terry Jan Reedy
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Unicode failure Terry Reedy <tjreedy@udel.edu> - 2015-12-04 18:28 -0500
csiph-web