Marc-Andre Lemburg added the comment: On 24.06.2013 16:35, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > MAL> Please leave the function as it is, i.e. a 1-1 mapping to the > MAL> official, non-changing Unicode name reference (including > MAL> spelling errors, etc). Same with code points that have no name. > > Since we have code points with no name - it is not 1-1 mapping but 1 to 0 or > 1.
True, it's not 1-1 in the mathematical sense (bijective), only surjective. However, it is 1-1 for all code points which have a name assigned. > Unicode Standard recommends using "Code Point Labels" "To provide unique, > meaningful labels for code points that do not have character names." (Section > 4.9.) > > These labels are not very useful: > > Control: control-NNNN > Reserved: reserved-NNNN > Noncharacter: noncharacter-NNNN > Private-Use: private-use-NNNN > Surrogate: surrogate-NNNN I don't any advantage of using these over plain \uXXXX codes. > According to the description in NameAliases.txt: > > # The formal name aliases are part of the Unicode character namespace, which > # includes the character names and the names of named character sequences. > > I believe this means that formal name aliases are as official as the > character names. Yes, but they are official aliases, not official code point names :-) > If we don't change the default, what is the downside in adding an optional > type argument to unicodedata.name()? After all, according to the standard, > aliases *are* names, just a different *type* of names. The .aliases() function would have to return a list, not a single name, so a parameter would cause the return type to change, which is not a good idea. A new function also makes the origin of these names clear to the user. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18234> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com