flying sheep added the comment:
IDK if it came with unicode 7.0, but there is clarification:
# Note that currently the only instances of multiple aliases of the same
# type for a single code point are either of type "control" or "abbreviation".
# An alias of type "abbreviation" can, in principle, be added for any code
# point, although currently aliases of type "correction" do not have
# any additional aliases of type "abbreviation". Such relationships
# are not enforced by stability policies.
it says “currently”, so it isn’t guaranteed to stay that way, and other types
could also be specified multiple times in the future.
so as much as i’d like it if we could follow Alexander’s proposal, i think we
shouldn’t extend the function that way if it would either return a name string,
a default value, a list of aliases, or raise an exception: too complex.
i think we should create:
unicodedata.aliases(chr,
type=(None|'correction'|'control'|'alternate'|'figment'|'abbreviation'))
and make
aliases(chr) return a dict with all aliases for the character, and make
aliases(chr, type) return a list of aliases for that type (possibly empty)
examples:
aliases('\b') == {'control': ['BACKSPACE'], 'abbreviation': ['BS']}
aliases('\b', 'control') == ['BACKSPACE']
aliases('b') == {}
aliases('b', 'control') == []
---
alternative: when specifying a type, it’ll raise an error if no alias of this
type exists. but because of the sparse nature of aliases i’m against that.
----------
nosy: +flying sheep
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18234>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
