On Fri, 23 Dec 2022 at 21:02, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Dec 23, 2022 at 06:02:39PM +0900, Stephen J. Turnbull wrote:
Many would argue that (POSIX) locales aren't a good fit for anything. :-)
:-)
I agree that it's kind of hard to see anything more complex than a fixed table for the entire Unicode repertoire belonging in str, though.
I think for practical reasons, we don't want to overload the builtin str class with excessive complexity. But the string module? Or third-party libraries?
Not really convinced that it belongs in string, but it could go in unicodedata (if it's lifted straight from the Unicode standards and associated data files), locale, or any sort of third-party library. I think this would be a useful feature to have, although it'll probably end up needing a LOT of information (you can't just say "give me a locale-correct uppercasing of this string" without further context). So IMO it should be third-party. Went looking on PyPI to see what already exists, but I didn't find anything. Might just be that I didn't pick the right keywords to look for though. ChrisA