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 lemburg
Recipients belopolsky, benjamin.peterson, ezio.melotti, lemburg, loewis, serhiy.storchaka
Date 2013-06-24.14:58:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <51C85EA1.6030408@egenix.com>
In-reply-to <1372084514.95.0.693019342702.issue18234@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2013-06-24 14:58:44lemburgsetrecipients: + lemburg, loewis, belopolsky, benjamin.peterson, ezio.melotti, serhiy.storchaka
2013-06-24 14:58:44lemburglinkissue18234 messages
2013-06-24 14:58:44lemburgcreate