<div dir="ltr">I am starting a new thread to discuss an idea that is orthogonal to Steven D'Aprano's \U+NNNN proposal.<br><br>The Unicode Standard defines five types of code points for which it does not provide a unique Name property.  These types are: Control, Reserved, Noncharacter, Private-use and Surrogate.<br>
<br>When a unique descriptive label is required for any such code point, the standard recommends constructing a label as follows: "For each code point type without character names, code point labels are constructed by using a lowercase prefix derived from the code point type, followed by a hyphen-minus and then a 4- to 6-digit hexadecimal representation of the code point."<br>
<br>I propose adding support for these labels to unicodedata.lookup(), \N{..} and <a href="http://unicodedata.name">unicodedata.name</a>() (or unicodedata.label()).<br><br>In the previous thread, there was a disagreement on whether invalid labels (such as reserved-0009 instead of control-0009) should be accepted.  I will address this in my response to Stephen Turnbull's e-mail below.<br>
<br>Another question is how to add support for generating the labels in a backward compatible manner.<br><br>Currently <a href="http://unicodedata.name">unicodedata.name</a>() raises ValueError when no name is available for a code point:<br>
<br>>>> <a href="http://unicodedata.name">unicodedata.name</a>(chr(0x0009))<br>Traceback (most recent call last):<br>  File "<stdin>", line 1, in <module><br>ValueError: no such name<br><br>
Since <a href="http://unicodedata.name">unicodedata.name</a>() also supports specifying default, it is unlikely that users write code like this<br><br>try:<br>   name =  <a href="http://unicodedata.name">unicodedata.name</a>(x)<br>
except ValueError:<br>   name = 'U+{:04X}'.format(ord(x))<br><br>instead of<br><br>name = <a href="http://unicodedata.name">unicodedata.name</a>(x, '') or 'U+{:04X}'.format(ord(x))<br><br>However, the most conservative approach is not to change the behavior of <a href="http://unicodedata.name">unicodedata.name</a>() and provide a new function unicodedata.label(). <br>
<br><br>On Fri, Aug 2, 2013 at 3:36 AM, Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br>><br>> Alexander Belopolsky writes:<br>>  > .. why would you write \N{reserved-NNNN} instead of<br>
>  > \uNNNN to begin with?<br>><br>> I wouldn't.  The problem isn't writing "\N{reserved-50000}".  It's<br>> the other way around: I want to *write* "\N{control-50000}" which<br>
> expresses my intent in Python 3.5 and not have it blow up in Python<br>> 3.4 which uses an older UCD where U+50000 is unassigned.<br><br><br> "\N{control-50000}" will blow up in every past, present or future Python version.  Since Unicode 1.1.5, "The General_Category property value Control (Cc) is immutable: the set of code points with that value will never change." <<a href="http://www.unicode.org/policies/stability_policy.html">http://www.unicode.org/policies/stability_policy.html</a>><br>
<br><br>>  > With the possible exception or reserved-, on a rare occasion when you<br>>  > want to be explicit about the character type, it is useful to be<br>>  > strict.<br>><br>> As explained above, strictness is not backward compatible with older<br>
> versions of the UCD that might be in use in older versions of Python.<br>><br><div><br></div><div>This is not an issue for versions of Python that currently exist because they do not support \N{<type-prefix>-NNNN} syntax at all.   What may happen if my proposal is accepted is that \N{reserved-50000} will be valid in Python 3.N but invalid in 3.N+1 for some N > 3.  If this becomes an issue, we can solve this problem when the time comes.  It is always easier to relax the rules than to make them stricter.  Yet, I still don't see the problem.  You can already write</div>
<div><br></div><div>assert unicodedata.category(chr(0x50000)) == 'Cn'</div><div><br></div><div>in your code and this will blow up in any future version that will use UCD with U+50000 assigned.</div><div><br></div>
<div>You can think of "\N{<type-prefix>-NNNN}" as a syntax sugar for "\uNNNN" followed by an assert.</div><div><br></div><div><br></div><div><br></div></div>