On 10 July 2018 at 09:45, Pander <pan...@users.sourceforge.net> wrote:
>
> On 07/10/2018 10:34 AM, Paul Moore wrote:
>> ...
>> Is this a Unicode Consortium standard, or a 3rd party project? The
>> website wasn't completely clear on the matter, but there's nothing I
>> could find on the Unicode website about translations of the standard
>> name (there's also nothing that specifically explains the choice to
>> use English for the standard names...). If it's not part of the
>> standard, then there's an argument that the Python implementation of
>> this should also be a 3rd party package, rather than being in the
>> stdlib. Is this feature available on PyPI at the moment?
> This is a third party initiative. The translations are contributed by
> volunteers. I have talked with Python core developers and they suggested
> to post this here, as it is for them out of scope for Python std lib. At
> the moment there is no implementation yet. That is what I would like to
> discuss here.
Thanks for the clarification. I'd say that in that case, this should
probably be created as a 3rd party project on PyPI in the first
instance. If it becomes popular and is useful to a sufficiently large
user base, it could then be included in the stdlib. Your example code
uses a separate unicodedata_l10n package, and it would be very easy to
publish that on PyPI and later move it unchanged to the stdlib if
needed.
>> Also, would this not lead to non-English speakers expecting that the
>> localised names would work in "\N{...}" notation?
> Don't know. If an implementation has been made, it should be positioned
> very carefully.
Having this as a 3rd party project would make it much less likely that
users would expect \N support, IMO.
Paul
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
