For now re.split doesn't split with zero-width regex. There are a number of issues for this (bpo-852532, bpo-988761, bpo-3262, bpo-22817). This is definitely a bug, but fixing this bug will likely break existing code which use regular expressions which can match zero-width (e.g. re.split('(:*)', 'ab')).

I propose to deprecate splitting on possible zero-width regular expressions. This expressions either not work at all as expected (r'\b' never split) or can be rewritten to not match empty string ('(:*)' to '(:+)').

In next release (3.6) we can convert deprecation warning to the exception, an then after transitional period change behavior to more correct handling zero-width matches without breaking backward compatibility.

I there are no objections I'm going to commit the patch soon.

Now patterns which could match only an empty string (e.g. '(?m)^$' or '(?<=\w-)(?=\w)') are rejected at all. They never worked with current regex engine. Updated the documentation.

Could anyone please make a review and correct my wording. It is desirable to get this in alpha 1 and receive early feedback.

I don't really understand why "this is definitely a bug".

Because users expect that split() supports zero-width patterns (as sub() supports them) and regexps in other languages support splitting on zero-width patterns. This looks as accidental implementation detail (see my patch in bpo-22817 -- the difference is pretty small) frozen in the ages for backward compatibility. We can't change this behavior in maintained releases because this will break mach code which accidentally use zero-width patterns. But we can change it in future as new feature, after deprecating current behavior. This would be very useful feature. For example it would allow to simplify and speed up the regex used for splitting on hyphens in textwrap (something like r'(?<=\w-)(?=\w)').

Could anyone please make a review (mainly documentation)? It would be good to get this change in first alpha.

Thank you Ezio for your review. Updated patch includes most of your suggestions. But I think some places still can be dim.

Updated patch includes Ezio's suggestions. Thank you Ezio, they looks great to me.

I hesitate about warning type. Originally I was going to emit a DeprecationWarning in 3.5, may be change it to a UserWarning in 3.6, and raise a ValueError or change behavior in 3.7. What would be better?

May be RuntimeWarning or FutureWarning are more appropriate?

DeprecationWarning: Base class for warnings about deprecated features.
UserWarning: Base class for warnings generated by user code.
RuntimeWarning: Base class for warnings about dubious runtime behavior.
FutureWarning: Base class for warnings about constructs that will change semantically in the future.

I think FutureWarning would be a good choice here, since we are going to change the semantics of a construct (before zero-width pattern didn't split -> in the future they will).

New changeset 7c667d8ae10d by Serhiy Storchaka in branch 'default':
Issue bpo-22818: Splitting on a pattern that could match an empty string now
https://hg.python.org/cpython/rev/7c667d8ae10d

Thank you Ezio and Berker for your reviews.