Don’t allow empty regex pattern

[tim.one (Tim Peters)]

@acampove

An empty string and .* are not the same, and should not be the same.

And, in fact, they aren’t treated the same.

However they are treated as if they were the same in places like:

import re

pattern = re.compile('')

x = bool(pattern.match('1234'))
print(x) # This is True

How is 1234 matching an empty string intuitive?

It isn’t, but that’s not what you asked for,.You asked whether '1234' starts (match()) with an empty string. And it does:

>>> '1234'.index('')
0

Thoroughly consistent. If you want to know whether all of '1234' matches an empty string, use fullmatch() instead:

>>> import re
>>> print(re.fullmatch('', '1234'))
None

Of course it doesn’t.

Another example of bad design are the muttable defaults. They are completely counterintuitive, no one needs the behavior they have and we only know about them because of the problems they cause.

I’m losing my presumption of good will There are many options because many use cases want different behaviors in different cases. The defaults picked overwhelmingly match industry-wide behaviors for regexps, except that Python seems unusual in using match() to mean “restrict matches to start at the beginning” (in many other implementations, match() is used to ask for what Python means by search()).. The defaults are most convenient for what seems to be the most common cases; do case-sensitive matching against single lines of text (so, e.g., a lone period does not match a newline character by default).

In fact, the only option I routinely use is re.VERBOSE.

The worst aspect of regexps is that they do backtracking, which is rarely what people actually want, and is the cause of the overwhelmingly most likely real-life problems: regexps that don’t match what you actually want them to match, and that are prone to talking exponential time to fail to match inputs you didn’t anticipate (“catastrophe[hic backtracking”).

More modern implementations (like Python’s) include more magical constructs, like “possessive quantifiers” and “atomic groups” that can be used to cut off possibilities for unwanted backtracking, but in all they make the already-cryptic regexp “language” even more cryptic.

The best use for regexps is to do simple lexing (“identify the next token”) in a loop (like the old Unix™ lex tool), and put higher-level parsing logic in code (like the old yacc tool). Even for all their arcane complications, regexps aren’t even adequate for “simple” parsing tasks like “match the longest substring balanced with respect to parentheses”). In fact, few people seem able to write a correct and “always fast, even in failing cases” regexp to match a Python triple-quoted string literal.

Those are problems people actually wrestle with. You’re the only one to date who owned up to being burned by pausing an empty string as the pattern, and despite that it does exactly what you asked it to do .