This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jim.Jewett
Recipients Ben Griffin, Jim.Jewett, epaine, ned.deily, ronaldoussoren, terry.reedy
Date 2020-07-11.18:15:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1594491359.69.0.540298614145.issue41212@roundup.psfhosted.org>
In-reply-to
Content
@Ben Griffin -- Unicode has defined astral characters for a while, but they were explicitly intended for rare characters, with any living languages intended for the basic plane.  It is only the most recent releases of unicode that have broken the "most people won't need this" expectation, so it wasn't unreasonable for languages targeting memory-constrained devices to make astral support at best a compile-time operation.  

I've seen a draft for an upcoming spec update of an old but still-supported language (extended Gerber, for photoplotting machines) that "handles" this simply by clarifying that their unicode support is limited to characters < 65K.  Given that their use of unicode is essentially limited to comments, and there is plenty of hardware that can't be updated ... this is may well be correct.

Python itself does the right thing, and tcl can't do the right thing anyhow without font support ... so this may be fixed in less time than it would take to replace Tk/Tcl.  If you need a faster workaround, consider a private-use-area and private font.
History
Date User Action Args
2020-07-11 18:15:59Jim.Jewettsetrecipients: + Jim.Jewett, terry.reedy, ronaldoussoren, ned.deily, Ben Griffin, epaine
2020-07-11 18:15:59Jim.Jewettsetmessageid: <1594491359.69.0.540298614145.issue41212@roundup.psfhosted.org>
2020-07-11 18:15:59Jim.Jewettlinkissue41212 messages
2020-07-11 18:15:59Jim.Jewettcreate