Ned Deily <n...@python.org> added the comment:
Thanks for the report. macOS does not ship with the GNU readline library due to its GPL licensing and instead relies on the BSD editline library, libedit, which, while providing similar functionality, has a different API than GNU readline. However, editline does provide a compatibility layer that provides much, but not all, of the GNU readline API. Third-party programs like Python have linked with that compatibility layer for many years but there are some shortcomings with it, like when trying to use full Unicode in the REPL as in your case. There have been many reports over the years of similar problems in Python and in other products that use the readline compatibility layer of libedit. If this behavior is unacceptable, the standard recommendation on the webs has been to use a version of the product that is linked with GNU readline rather than with libedit's readline layer. (Alas, Python does not support directly linking with libedit's native API which would likely avoid these issues.) The potential drawback to using GNU readline is that it is licensed under GPL v3 which may be unacceptable for some users. There is a third-party package on PyPI called gnureadline which allowed replacing the Python readline module with one linked with GNU readline; I'm not sure what its status is as it doesn't appear to have been updated recently. Alternatively, there are Python distributions from other sources (like Homebrew and MacPorts) that optionally provide GNU readline for Python. Hope that helps! ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45904> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
