Le dimanche 26 novembre 2017 05:53:55 UTC+1, Rustom Mody a ÄCcritâ : > On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > > Hi, my goal is to obtain an interpreter that internally > > > uses UCS-2. Such a simple code should print 65535: > > > > > > import sys > > > print sys.maxunicode > > > > > > This is enabled in Windows, but I want the same in Linux. > > > What options have I pass to the configure script? > > > > Why do you want to? What useful value do you have in creating this > > buggy interpreter? > > I see that you are familiar with this bug: https://bugs.python.org/issue13153 > > And I see it or something very close is still buggy in python 3.5 > [No it does not allow me to paste an SMP char but if I open a file containing > one it crashes and rather messily â ö no way to close the idle other than killing > the shell] > > No thats not a diatribe against idle; just that its reasonable to want python > to support work-arounds for reasonably common bugs in the current unicode-ecosystem
Yes, it's a little bit extraordinary, to see a language which is supposed to work internally in a "UCS-2/UTF-16" (very quoted) mode with a graphical toolkit also woking in a "UCS-2/UTF-16" succeeds to raise UTF-8 errors (!). Patches over patches over patches over pathches ... will never solve what is wrong by design. As semi correctly pointed, for serious Unicode works use serious tools with a correct Unicode implementation. There are even tools, where the following is printable: >>> >>> '\ud800\udc00'.isprintable() False >>>
-- https://mail.python.org/mailman/listinfo/python-list
