New sequences for Unicode groups and block ranges needed

[gmarketer]

BPO	1528154
Nosy	@malemburg, @loewis, @terryjreedy, @devdanzin, @ezio-melotti
Dependencies	bpo-2636: Adding a new regex module (compatible with re)

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2006-07-25.04:44:06.000>
labels = ['expert-regex', 'type-feature', 'expert-unicode']
title = 'New sequences for Unicode groups and block ranges needed'
updated_at = <Date 2019-03-15.23:59:53.114>
user = 'https://bugs.python.org/gmarketer'

bugs.python.org fields:

activity = <Date 2019-03-15.23:59:53.114>
actor = 'BreamoreBoy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Regular Expressions', 'Unicode']
creation = <Date 2006-07-25.04:44:06.000>
creator = 'gmarketer'
dependencies = ['2636']
files = []
hgrepos = []
issue_num = 1528154
keywords = []
message_count = 15.0
messages = ['54861', '54862', '54863', '54864', '54865', '54866', '84503', '84532', '84544', '100129', '130412', '185757', '185759', '221632', '221761']
nosy_count = 8.0
nosy_names = ['lemburg', 'loewis', 'effbot', 'terry.reedy', 'ajaksu2', 'gmarketer', 'ezio.melotti', 'mrabarnett']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1528154'
versions = ['Python 3.4']

[gmarketer]

The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:

• All uppercase letters
• All lowercase letters

[malemburg]

Logged In: YES
user_id=38388

Could you make your request a little more specific ?

We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.

[gmarketer]

Logged In: YES
user_id=1334865

We need to process several strings in utf-8 and need to use
regular expressions to match pattern, for ex.:
r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY"

We don't know how to implement this logic by our hands.

Also, I found this logic implemented in Microsoft dot NET
regular expressions:

\p{name} Matches any character in the named character
class 'name'. Supported names are Unicode groups and block
ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc
(currency).

\P{name} Matches text not included in the named
character class 'name'.

We need same logic in regular expressions.

[loewis]

Logged In: YES
user_id=21627

If anything, I think Python should implement Unicode TR#18:

http://www.unicode.org/unicode/reports/tr18/

This does include the \p notation for property expressions,
e.g. \p{Ll} or \p{East Asian Width:Narrow}.

We currently don't include the Script property, so \p{Greek}
could not be implemented (we can, of course, add support for
the script property). I can't find anything in the report
that makes \p{IsGreek} valid, so we shouldn't support it.

[effbot]

note that posix uses a special set syntax, [:name:], for this purpose:

[:alnum:] [:cntrl:] [:lower:] [:space:]
[:alpha:] [:digit:] [:print:] [:upper:]
[:blank:] [:graph:] [:punct:] [:xdigit:]

adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory.

[effbot]

note that posix uses a special set syntax, [:name:], for this purpose:

[:alnum:] [:cntrl:] [:lower:] [:space:]
[:alpha:] [:digit:] [:print:] [:upper:]
[:blank:] [:graph:] [:punct:] [:xdigit:]

adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory.

[devdanzin]

Has this been addressed for 2.6/3.0? Do the LOCALE and UNICODE constants
cover this?

[loewis]

No progress has been made. I still maintain that TR18 should be
implemented.

I'm not so sure whether the POSIX special groups should be provided. My
understanding is that they originally were meant to integrate with the
locale support, and change with locale. For Unicode, Annex C of TR18 makes
a recommendation on how to provide the POSIX properties, and offers two
alternative definitions: Standard Recommendation and POSIX Compatible.
That alone tells me that it is best not to provide support for them:
refuse the temptation to guess.

[mrabarnett]

I implemented \p, \P and [:...:] for the simple categories (eg "Lu" and
"upper", but not "IsGreek") in the work I did for issue bpo-2636.