[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole added the comment: Is there any hope that something like this patch will make it into a future version? As far as I can see, entering accented characters is currently impossible on the latest release versions of python...or am I missing something? -- nosy: +Nicholas.Cole ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole added the comment: The bug is marked "Test Needed". I am very keen to see this issue fixed, and would be very willing to help, but I don't really know what is still required. As far as I can see there is a patch waiting - what is the hold up? -- ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12568] Add functions to get the width in columns of a character
Changes by Nicholas Cole : -- nosy: +Nicholas.Cole ___ Python tracker <http://bugs.python.org/issue12568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole added the comment: > Nobody wanted to take the responsability of the choice for get_wch(): add a > new method or patch getch() ;-) I suspect that a new method is the right way to go, here. I see it has been moved to "committed/rejected" status - does that mean that it might still go in, or that it is rejected? > I think that the Unicode support of curses in Python 3 is just completly > broken It certainly is less than ideal. ;-) -- ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12567] curses implementation of Unicode is wrong in Python 3
Nicholas Cole added the comment: I think that some platforms do not have wide character support, though I could be wrong. The FAQ here: http://invisible-island.net/ncurses/ncurses.faq.html has a list of those that do and those that don't, but I don't know how up to date it is. -- ___ Python tracker <http://bugs.python.org/issue12567> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12567] curses implementation of Unicode is wrong in Python 3
Nicholas Cole added the comment: There are now several bugs dealing with related issues here. Are we any closer to a solution to any of them? The suggested patches look like a good idea - what needs to happen for them to move forward? -- ___ Python tracker <http://bugs.python.org/issue12567> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12567] curses implementation of Unicode is wrong in Python 3
Nicholas Cole added the comment: It looks to me as if the documentation in the release candidates for 2.7.3 and 3.2.3 haven't been updated to include the new curses fixes. Is that correct? -- ___ Python tracker <http://bugs.python.org/issue12567> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole added the comment: I hope that this is the right bug to file this on (I'm getting lost in all of the curses bugs!). I'm testing out the 3.3a1, and I've run into the following issue. On previous releases addch() could accept curses.ACS_HLINE and similar. Attempting to use the same code now raises the exception: OverflowError: byte doesn't fit in chtype. I'm sure this is related to the new code that uses addwstr(), but currently code that used to work will crash. I can't work out a fix myself, because I don't fully understand the problem, but I'm happy to provide sample code if it will help. Nicholas -- ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
New submission from Nicholas Cole : The following code works on Python versions prior to 3.3a1: import curses def test_screen(screen): screen.addch(5,5, curses.ACS_HLINE) screen.refresh() curses.wrapper(test_screen) On python3.3, the program produces the following traceback: Traceback (most recent call last): File "/tmp/p.py", line 7, in curses.wrapper(test_screen) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/curses/__init__.py", line 94, in wrapper return func(stdscr, *args, **kwds) File "/tmp/p.py", line 4, in test_screen screen.addch(5,5, curses.ACS_HLINE) OverflowError: byte doesn't fit in chtype -- components: Library (Lib) messages: 155118 nosy: Nicholas.Cole priority: normal severity: normal status: open title: curses addch broken on Python3.3a1 versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6755] Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
Nicholas Cole added the comment: On Wed, Mar 7, 2012 at 7:40 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Since this bug is about adding a new feature, it is unlikely to be the > correct bug for this to be against. > > Given that you've identified a regression, I suggest you open a new bug with > a reproducer, and we'll set it to release blocker. I've created issue 14223. I hope I've done so correctly. Best wishes, Nicholas -- ___ Python tracker <http://bugs.python.org/issue6755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12568] Add functions to get the width in columns of a character
Nicholas Cole added the comment: Could we have an update on the status of this? I ask because if 3.3 is going to (finally) fix unicode for curses, it would be really nice if it were possible to calculate the width of what's being displayed! It looks as if there was never quite agreement on the proper API -- ___ Python tracker <http://bugs.python.org/issue12568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12568] Add functions to get the width in columns of a character
Nicholas Cole added the comment: Martin: sorry to be completely dense, but I can't get this to work properly with the python3.3a1 build. Could you post some example code? -- ___ Python tracker <http://bugs.python.org/issue12568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12568] Add functions to get the width in columns of a character
Nicholas Cole added the comment: Marting and Poq: I think the sample code shows up a real problem. "Ambiguous" characters according to unicode may be rendered by curses in different ways. Don't we need a function that actually reports how curses is going to print a given string, rather than just reporting what the unicode standard says? -- ___ Python tracker <http://bugs.python.org/issue12568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12568] Add functions to get the width in columns of a character
Nicholas Cole added the comment: Poq: I agree. Guessing from the Unicode standard is going to lead to users having to write some complicated code that people are going have to reinvent over and over, and is not going to be accurate with respect to curses. I'd favour exposing wcwidth. Martin: I agree that there are going to be cases where it is not correct because the terminal does something strange, but what we need is something that gets as close as possible to what the terminal is likely to be doing (the Unicode standard itself is not really the issue for curses stuff). So whether it is called wcwidth or wcswidth I don't really mind, but I think it would be useful. The other alternative is to include one of the other ideas that have been mentioned in this thread as part of the library, I suppose, so that people don't have to keep reinventing the wheel for themselves. The one thing I really don't favour is shipping something that supports wide characters, but gives the users no way of guessing whether or not that is what they are printing, because that is surely going to break a lot of applications. -- ___ Python tracker <http://bugs.python.org/issue12568> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12567] curses implementation of Unicode is wrong in Python 3
Nicholas Cole added the comment: Testing the Python3.3a2 build on OS X - the exception AttributeError: '_curses.curses window' object has no attribute 'get_wch' is still being raised. I don't have a Linux build I can easily test with. Is this a particular problem with the OS X build? -- ___ Python tracker <http://bugs.python.org/issue12567> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: I'm reopening this bug because I've noticed that in Python3.3rc1, although trying to print curses.ACS_HLINE and other such characters no long cause an Exception, only blank characters are printed to the screen. Tested with both Terminal.App and xterm running under XQuartz. Here is some minimal test code, that will print a line on Python2.x but a blank screen on Python3.3rc1. -- resolution: fixed -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: import curses def test_screen(screen): screen.addch(5,5, curses.ACS_HLINE) screen.addch(5,6, curses.ACS_HLINE) screen.refresh() curses.napms(2000) curses.wrapper(test_screen) -- ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: Unless I'm getting the build process wrong (possible, because I haven't tried testing fixes before), this fix isn't working for me. -- ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: > Unless I'm getting the build process wrong (possible, because > I haven't tried testing fixes before), this fix isn't working for me. Oh did you compile Python? Did you install it? Yes, I tried compiling it. #./configure MACOSX_DEPLOYMENT_TARGET=10.8 --enable-framework --with-universal-archs="64-bit" CFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" && make -j6 && make install Do you have libncursesw? => do you have the function curses.unget_wch? yes... Python 3.3.0rc1+ (default, Sep 3 2012, 09:45:35) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import curses >>> curses.unget_wch() Traceback (most recent call last): File "", line 1, in _curses.error: must call initscr() first >>> curses.version b'2.2' >>> What is the version of your libcurses[w] library? There are issues on libncurses 5.7. I think Ned Bat changed the script to compile Python on Mac to use a builtin copy of libncurses 5.9. See: http://bugs.python.org/issue14225#msg163323 How do I check which version it was built against? The messages from ./configure just say that the tests pass, not which version it has found. -- ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: On Mon, Sep 3, 2012 at 3:15 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> How do I check which version it was built against? > > On Linux, I use: > > $ ldd /usr/lib/python2.7/lib-dynload/_curses.so |grep curses > libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb76d) > $ ls -l /lib/i386-linux-gnu/libncursesw.so.5 > lrwxrwxrwx 1 root root 18 nov. 18 2011 > /lib/i386-linux-gnu/libncursesw.so.5 -> libncursesw.so.5.9 > > => version 5.9 I get Version 5.4, which seems very out of date (I'm running the latest release of OS X) but: nicholas$ ls -l /usr/lib/libncurses. libncurses.5.4.dylib libncurses.5.dyliblibncurses.dylib NPSC:mnpyscreen nicholas$ ls -l /usr/lib/libncurses.dylib lrwxr-xr-x 1 root wheel 20 25 Jul 18:32 /usr/lib/libncurses.dylib -> libncurses.5.4.dylib nicholas$ ldd /usr/lib/python2.7/lib-dynload/_curses.so |grep curses /usr/lib/python2.7/lib-dynload/_curses.so: /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) Can that possibly be right?? -- ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14223] curses addch broken on Python3.3a1
Nicholas Cole added the comment: I've just tried the OS X build of 3.3rc2, and this has been fixed. Thank you! -- ___ Python tracker <http://bugs.python.org/issue14223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
