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
Implement utf-8-bmp codec #58512
Comments
Tkinter (and IDLE specially) can use only UCS-2 characters. |
The solution outlined in the issue title ("utf-8-bmp codec") sounds like a rather dubious idea. |
pitrou: can you elaborate? |
''.join(c if ord(c) < 0x10000 else escape(c) for c in s) |
What is this codec? What do you mean by "escpe non-ascii"? |
This codec is one that is equal to UTF-8, but restricted to the BMP. For non-BMP character, the error handler is called. It will be the stdout codec for the IDLE interactive shell, causing non-BMP results to be ascii() escaped. |
Tkinter (as Tcl itself) has no support of non-BMP characters in any form. It will allow to support BMP well and control processing of non-BMP in IDLE. About your second question. |
Example: >>> '\u0100'
'Ā'
>>> '\u0100\U00010000'
'\u0100\U00010000'
>>> print('\u0100')
Ā
>>> print('\u0100\U00010000')
Traceback (most recent call last):
File "<pyshell#33>", line 1, in <module>
print('\u0100\U00010000')
UnicodeEncodeError: 'UCS-2' codec can't encode characters in position 1-1: Non-BMP character not supported in Tk But I think that it is too specific problem and too specific solution. It would be better if IDLE itself escapes the string in the most appropriate way. def utf8bmp_encode(s):
return ''.join(c if ord(c) <= 0xffff else '\\U%08x' % ord(c) for c in s).encode('utf-8') or def utf8bmp_encode(s):
return re.sub('[^\x00-\uffff]', lambda m: '\\U%08x' % ord(m.group()), s).encode('utf-8') |
The way is named 'codec'. |
That is not implementable correctly. If you think otherwise, please |
May be I did not correctly understand the problem, but I can assume, 'Агов!\U00010000' |
Sorry, the mail daemon has eaten a piece of example. >>> '\u0410\u0433\u043e\u0432!\U00010000'
'Агов!\U00010000' |
Andrew, the patch solves your issue? |
The patch is incorrect, i.e. it deviates from what the command line interface does. When you try to write to sys.stdout, and the characters are not supported you get UnicodeError. Only when it is interactive mode, and tries to represent some result, ascii escaping happens. |
I don't see what the patch worse than the current behavior. Unpatched:
>>> ''.join(map(chr, [76, 246, 119, 105, 115]))
'Löwis'
>>> ''.join(map(chr, [76, 246, 119, 105, 115, 65536]))
'L\xf6wis\U00010000'
Patched:
>>> ''.join(map(chr, [76, 246, 119, 105, 115]))
'Löwis'
>>> ''.join(map(chr, [76, 246, 119, 105, 115, 65536]))
'Löwis\U00010000' In the case of the Cyrillic alphabet all text becomes unreadable, if there are some non-bmp characters in it. |
And indeed, that's the correct, desired behavior, as it models what the If you want to change this, you need to also change the interactive console, |
I take that back; the interactive shell uses the backslashescape error handler. Still, I don't think IDLE should setup a displayhook in the first place. What if an application replaces the displayhook? |
IDLE *is* the application. If another application that uses the idlelib, replace displayhook, it |
Serhiy, I like to fix tkinter itself, not only IDLE. |
No, IDLE is the development environment. The application is |
I don't understand how the utf-8-bmp codec will help to fix the tkinter. To fix the tkinter, you need to fix the Tcl/Tk, but it is outside of Python. While Tcl does not support non-bmp characters, correct and non-ambiguous working with non-bmp characters is not possible. You should choose the method of encoding of non-bmp characters and these methods will be different for different applications. |
If the application replaces the displayhook, than it is the development |
Andrew, imagine that the utf-8-bmp codec is already there (I will do it |
Any chance to commit the patch before final feature freeze? |
Pending doing some experiments with current and patched code, and reading the rpc code, I believe I would like to see the patch applied. I don't care about whether the patch defines a 'codec' or what its name would be. What i do want is for the Idle Shell to display unicode strings produced by python code as faithfully as possible, without raising an exception, given the limitations of tk and the selected font. |
Is it always the case, or does depend on a compilation flag of Tcl or Tk? |
In theory Tcl/Tk can be built with 32-bit Tcl_Char. But I doubt that this option is well tested. In any case on Linux Python depends on system Tcl/Tk. |
Would it make sense to compile Tcl/Tk with 32-bit Tcl_Char on Windows? I think that we embed our own build ot Tcl/Tk, right? |
In 3.6, Python's use of the Windows console was changed to work much better with unicode. As a result, IDLE is now worse rather than better than the console on Windows. I plan to do something before 3.7.0. |
October 2019, Serhiy solved the display issue with a _tkinter patch for python/cpython#57362.
bpo-13153: Use OS native encoding for converting between Python and Tcl. (GH-16545)
https://github.com/python/cpython/commit/06cb94bc8419b9a24df6b0d724fcd8e40c6971d6
In Windows IDLE Shell
>>> ''.join(map(chr, [76, 246, 119, 105, 115, 0x1F40D]))
'Löwis🐍'
except that the snake is black and white. (Many astral chars have no glyph and appear as a box.) In console REPL, the snake shows as box box space box. Pasting astral characters into edited code 'works' except that editing following code is messy because the astral char is multiple chars internally and the visible cursor no longer matches the internal index. (But pasting such no longer crashes IDLE.) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: