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 gregory.p.smith
Recipients ezio.melotti, gregory.p.smith, mark.dickinson, rhettinger, serhiy.storchaka, terry.reedy, vstinner, weightwatchers-carlanderson
Date 2021-03-20.22:01:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1616277696.36.0.86340511909.issue43520@roundup.psfhosted.org>
In-reply-to
Content
The proposal I like is for a unicode numeric normalization functions that return the ascii equivalent to exist.

These ideally belong in a third party PyPI library anyways, as they're the kind of thing that needs updating every time a new unicode revision comes out.  And there are often multiple cultural interpretations for some symbols, despite any standard, so you'd wind up with a variety of functions and options for which behavior to obtain.  That isn't the kind of thing that make for a good stdlib.

Doing this by default within the language syntax itself (and thus stdlib constructors) is potentially dangerous and confusing as everything in existence in the world today that processes Python source code already has baked in single-ascii-token assumptions.  While parsing and tooling could be evolved for that, it'd be a major ecosystem impacting change.
History
Date User Action Args
2021-03-20 22:01:36gregory.p.smithsetrecipients: + gregory.p.smith, rhettinger, terry.reedy, mark.dickinson, vstinner, ezio.melotti, serhiy.storchaka, weightwatchers-carlanderson
2021-03-20 22:01:36gregory.p.smithsetmessageid: <1616277696.36.0.86340511909.issue43520@roundup.psfhosted.org>
2021-03-20 22:01:36gregory.p.smithlinkissue43520 messages
2021-03-20 22:01:36gregory.p.smithcreate