Windows Unicode console support [Was: Bytes path support]
On 24 August 2014 04:27, Nick Coghlan <ncoghlan@gmail.com> wrote:
One of those areas is the fact that we still use the old 8-bit APIs to interact with the Windows console. Those are just as broken in a multilingual world as the other Windows 8-bit APIs, so Drekin came up with a project to expose the Windows console as a UTF-16-LE stream that uses the 16-bit APIs instead: https://pypi.python.org/pypi/win_unicode_console
I personally hope we'll be able to get the issues Drekin references there resolved for Python 3.5 - if other folks hope for the same thing, then one of the best ways to help that happen is to try out the win_unicode_console module and provide feedback on what does and doesn't work.
This looks very cool, and I plan on giving it a try. But I don't see any issues mentioned there (unless you mean the fact that it's not possible to hook into Python's interactive interpreter directly, but I don't see how that could be fixed in an external module). There's no open issues on the project's github tracker. I'd love to see this go into 3.5, so any more specific suggestions as to what would be needed to move it forwards would be great. Paul
On 27 August 2014 01:23, Paul Moore <p.f.moore@gmail.com> wrote:
On 24 August 2014 04:27, Nick Coghlan <ncoghlan@gmail.com> wrote:
One of those areas is the fact that we still use the old 8-bit APIs to interact with the Windows console. Those are just as broken in a multilingual world as the other Windows 8-bit APIs, so Drekin came up with a project to expose the Windows console as a UTF-16-LE stream that uses the 16-bit APIs instead: https://pypi.python.org/pypi/win_unicode_console
I personally hope we'll be able to get the issues Drekin references there resolved for Python 3.5 - if other folks hope for the same thing, then one of the best ways to help that happen is to try out the win_unicode_console module and provide feedback on what does and doesn't work.
This looks very cool, and I plan on giving it a try. But I don't see any issues mentioned there (unless you mean the fact that it's not possible to hook into Python's interactive interpreter directly, but I don't see how that could be fixed in an external module). There's no open issues on the project's github tracker.
There are two links to CPython issues from the project description: http://bugs.python.org/issue1602 http://bugs.python.org/issue17620 Part of the feedback on those was that as much as possible should be made available as a third party module before returning to the question of how to update CPython. If we can get additional confirmation that the module addresses the CLI integration issues, then we can take a closer look at switching CPython itself over. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 27 August 2014 09:09, Nick Coghlan <ncoghlan@gmail.com> wrote:
There are two links to CPython issues from the project description:
http://bugs.python.org/issue1602 http://bugs.python.org/issue17620
Part of the feedback on those was that as much as possible should be made available as a third party module before returning to the question of how to update CPython.
OK, ta. The only issues I'm seeing are that it doesn't play well with the interactive interpreter, which is a known problem but unfortunately makes it pretty hard for me to do any significant testing (nearly all of the stuff that I do which prints to the screen is in the REPL, or in IPython which has its own custom interpreter loop). If I come up with anything worth commenting on, I will do so (I assume that comments of the form "+1 me too!" are not needed ;-)) Paul
On 27 August 2014 10:46, Paul Moore <p.f.moore@gmail.com> wrote:
If I come up with anything worth commenting on, I will do so (I assume that comments of the form "+1 me too!" are not needed ;-))
Nevertheless, here's a "Me, too". I've just been writing some PyPI interrogation scripts, and it's absolutely awful having to deal with random encoding errors in the output. Being able to just print *anything* is a HUGE benefit. This is how sys.stdout should behave - presumably the Unix guys are now all rolling their eyes and saying "but it does - just use a proper OS" :-) Enlightened-ly y'rs, Paul
participants (2)
-
Nick Coghlan -
Paul Moore