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

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.

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.

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.

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.

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.

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

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.

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

\p{name} is supported for Unicode properties, scripts and blocks in my regex module (see issue #2636).

It also supports the POSIX set syntax, although I'm not sure that we really need to have 2 ways of doing it, eg \p{Alpha} and [[:Alpha:]].

Is there a practical issue left here? Mathew says his regex module does as requested, but adding that to the stdlib is a separate issue. Martin would like an implementation of Unicode TR18, but that is also another issue.

I am trying to decide if this issue still serves a purpose. It seems to be a request to add something to the existing re module. Fredrik semi-rejected the idea without a (micro)-pep. A python-ideas discussion is now another option. Matthew's regex implementation already has the feature, so this issue would be moot if it were ever part of the stdlib. But the fate of #2636 is unclear. Rereading, it now seems that implementing the feature in the current re module using the TR18 syntax would be this issue, if someone were to do it. So I will not close yet.

We should really just include "regex" in 3.4.

Is there an easy way to find out how many other issues have #2636 as a dependency?

This seems to be the only one currently.
Other issues might have closed in favor of #2636 though.