| .. _regex-howto: | |
| **************************** | |
| Regular Expression HOWTO | |
| **************************** | |
| :Author: A.M. Kuchling <amk@amk.ca> | |
| .. TODO: | |
| Document lookbehind assertions | |
| Better way of displaying a RE, a string, and what it matches | |
| Mention optional argument to match.groups() | |
| Unicode (at least a reference) | |
| .. topic:: Abstract | |
| This document is an introductory tutorial to using regular expressions in Python | |
| with the :mod:`re` module. It provides a gentler introduction than the | |
| corresponding section in the Library Reference. | |
| Introduction | |
| ============ | |
| Regular expressions (called REs, or regexes, or regex patterns) are essentially | |
| a tiny, highly specialized programming language embedded inside Python and made | |
| available through the :mod:`re` module. Using this little language, you specify | |
| the rules for the set of possible strings that you want to match; this set might | |
| contain English sentences, or e-mail addresses, or TeX commands, or anything you | |
| like. You can then ask questions such as "Does this string match the pattern?", | |
| or "Is there a match for the pattern anywhere in this string?". You can also | |
| use REs to modify a string or to split it apart in various ways. | |
| Regular expression patterns are compiled into a series of bytecodes which are | |
| then executed by a matching engine written in C. For advanced use, it may be | |
| necessary to pay careful attention to how the engine will execute a given RE, | |
| and write the RE in a certain way in order to produce bytecode that runs faster. | |
| Optimization isn't covered in this document, because it requires that you have a | |
| good understanding of the matching engine's internals. | |
| The regular expression language is relatively small and restricted, so not all | |
| possible string processing tasks can be done using regular expressions. There | |
| are also tasks that *can* be done with regular expressions, but the expressions | |
| turn out to be very complicated. In these cases, you may be better off writing | |
| Python code to do the processing; while Python code will be slower than an | |
| elaborate regular expression, it will also probably be more understandable. | |
| Simple Patterns | |
| =============== | |
| We'll start by learning about the simplest possible regular expressions. Since | |
| regular expressions are used to operate on strings, we'll begin with the most | |
| common task: matching characters. | |
| For a detailed explanation of the computer science underlying regular | |
| expressions (deterministic and non-deterministic finite automata), you can refer | |
| to almost any textbook on writing compilers. | |
| Matching Characters | |
| ------------------- | |
| Most letters and characters will simply match themselves. For example, the | |
| regular expression ``test`` will match the string ``test`` exactly. (You can | |
| enable a case-insensitive mode that would let this RE match ``Test`` or ``TEST`` | |
| as well; more about this later.) | |
| There are exceptions to this rule; some characters are special | |
| :dfn:`metacharacters`, and don't match themselves. Instead, they signal that | |
| some out-of-the-ordinary thing should be matched, or they affect other portions | |
| of the RE by repeating them or changing their meaning. Much of this document is | |
| devoted to discussing various metacharacters and what they do. | |
| Here's a complete list of the metacharacters; their meanings will be discussed | |
| in the rest of this HOWTO. | |
| .. code-block:: none | |
| . ^ $ * + ? { } [ ] \ | ( ) | |
| The first metacharacters we'll look at are ``[`` and ``]``. They're used for | |
| specifying a character class, which is a set of characters that you wish to | |
| match. Characters can be listed individually, or a range of characters can be | |
| indicated by giving two characters and separating them by a ``'-'``. For | |
| example, ``[abc]`` will match any of the characters ``a``, ``b``, or ``c``; this | |
| is the same as ``[a-c]``, which uses a range to express the same set of | |
| characters. If you wanted to match only lowercase letters, your RE would be | |
| ``[a-z]``. | |
| Metacharacters are not active inside classes. For example, ``[akm$]`` will | |
| match any of the characters ``'a'``, ``'k'``, ``'m'``, or ``'$'``; ``'$'`` is | |
| usually a metacharacter, but inside a character class it's stripped of its | |
| special nature. | |
| You can match the characters not listed within the class by :dfn:`complementing` | |
| the set. This is indicated by including a ``'^'`` as the first character of the | |
| class. For example, ``[^5]`` will match any character except ``'5'``. If the | |
| caret appears elsewhere in a character class, it does not have special meaning. | |
| For example: ``[5^]`` will match either a ``'5'`` or a ``'^'``. | |
| Perhaps the most important metacharacter is the backslash, ``\``. As in Python | |
| string literals, the backslash can be followed by various characters to signal | |
| various special sequences. It's also used to escape all the metacharacters so | |
| you can still match them in patterns; for example, if you need to match a ``[`` | |
| or ``\``, you can precede them with a backslash to remove their special | |
| meaning: ``\[`` or ``\\``. | |
| Some of the special sequences beginning with ``'\'`` represent | |
| predefined sets of characters that are often useful, such as the set | |
| of digits, the set of letters, or the set of anything that isn't | |
| whitespace. | |
| Let's take an example: ``\w`` matches any alphanumeric character. If | |
| the regex pattern is expressed in bytes, this is equivalent to the | |
| class ``[a-zA-Z0-9_]``. If the regex pattern is a string, ``\w`` will | |
| match all the characters marked as letters in the Unicode database | |
| provided by the :mod:`unicodedata` module. You can use the more | |
| restricted definition of ``\w`` in a string pattern by supplying the | |
| :const:`re.ASCII` flag when compiling the regular expression. | |
| The following list of special sequences isn't complete. For a complete | |
| list of sequences and expanded class definitions for Unicode string | |
| patterns, see the last part of :ref:`Regular Expression Syntax | |
| <re-syntax>` in the Standard Library reference. In general, the | |
| Unicode versions match any character that's in the appropriate | |
| category in the Unicode database. | |
| ``\d`` | |
| Matches any decimal digit; this is equivalent to the class ``[0-9]``. | |
| ``\D`` | |
| Matches any non-digit character; this is equivalent to the class ``[^0-9]``. | |
| ``\s`` | |
| Matches any whitespace character; this is equivalent to the class ``[ | |
| \t\n\r\f\v]``. | |
| ``\S`` | |
| Matches any non-whitespace character; this is equivalent to the class ``[^ | |
| \t\n\r\f\v]``. | |
| ``\w`` | |
| Matches any alphanumeric character; this is equivalent to the class | |
| ``[a-zA-Z0-9_]``. | |
| ``\W`` | |
| Matches any non-alphanumeric character; this is equivalent to the class | |
| ``[^a-zA-Z0-9_]``. | |
| These sequences can be included inside a character class. For example, | |
| ``[\s,.]`` is a character class that will match any whitespace character, or | |
| ``','`` or ``'.'``. | |
| The final metacharacter in this section is ``.``. It matches anything except a | |
| newline character, and there's an alternate mode (:const:`re.DOTALL`) where it will | |
| match even a newline. ``.`` is often used where you want to match "any | |
| character". | |
| Repeating Things | |
| ---------------- | |
| Being able to match varying sets of characters is the first thing regular | |
| expressions can do that isn't already possible with the methods available on | |
| strings. However, if that was the only additional capability of regexes, they | |
| wouldn't be much of an advance. Another capability is that you can specify that | |
| portions of the RE must be repeated a certain number of times. | |
| The first metacharacter for repeating things that we'll look at is ``*``. ``*`` | |
| doesn't match the literal character ``'*'``; instead, it specifies that the | |
| previous character can be matched zero or more times, instead of exactly once. | |
| For example, ``ca*t`` will match ``'ct'`` (0 ``'a'`` characters), ``'cat'`` (1 ``'a'``), | |
| ``'caaat'`` (3 ``'a'`` characters), and so forth. | |
| Repetitions such as ``*`` are :dfn:`greedy`; when repeating a RE, the matching | |
| engine will try to repeat it as many times as possible. If later portions of the | |
| pattern don't match, the matching engine will then back up and try again with | |
| fewer repetitions. | |
| A step-by-step example will make this more obvious. Let's consider the | |
| expression ``a[bcd]*b``. This matches the letter ``'a'``, zero or more letters | |
| from the class ``[bcd]``, and finally ends with a ``'b'``. Now imagine matching | |
| this RE against the string ``'abcbd'``. | |
| +------+-----------+---------------------------------+ | |
| | Step | Matched | Explanation | | |
| +======+===========+=================================+ | |
| | 1 | ``a`` | The ``a`` in the RE matches. | | |
| +------+-----------+---------------------------------+ | |
| | 2 | ``abcbd`` | The engine matches ``[bcd]*``, | | |
| | | | going as far as it can, which | | |
| | | | is to the end of the string. | | |
| +------+-----------+---------------------------------+ | |
| | 3 | *Failure* | The engine tries to match | | |
| | | | ``b``, but the current position | | |
| | | | is at the end of the string, so | | |
| | | | it fails. | | |
| +------+-----------+---------------------------------+ | |
| | 4 | ``abcb`` | Back up, so that ``[bcd]*`` | | |
| | | | matches one less character. | | |
| +------+-----------+---------------------------------+ | |
| | 5 | *Failure* | Try ``b`` again, but the | | |
| | | | current position is at the last | | |
| | | | character, which is a ``'d'``. | | |
| +------+-----------+---------------------------------+ | |
| | 6 | ``abc`` | Back up again, so that | | |
| | | | ``[bcd]*`` is only matching | | |
| | | | ``bc``. | | |
| +------+-----------+---------------------------------+ | |
| | 6 | ``abcb`` | Try ``b`` again. This time | | |
| | | | the character at the | | |
| | | | current position is ``'b'``, so | | |
| | | | it succeeds. | | |
| +------+-----------+---------------------------------+ | |
| The end of the RE has now been reached, and it has matched ``'abcb'``. This | |
| demonstrates how the matching engine goes as far as it can at first, and if no | |
| match is found it will then progressively back up and retry the rest of the RE | |
| again and again. It will back up until it has tried zero matches for | |
| ``[bcd]*``, and if that subsequently fails, the engine will conclude that the | |
| string doesn't match the RE at all. | |
| Another repeating metacharacter is ``+``, which matches one or more times. Pay | |
| careful attention to the difference between ``*`` and ``+``; ``*`` matches | |
| *zero* or more times, so whatever's being repeated may not be present at all, | |
| while ``+`` requires at least *one* occurrence. To use a similar example, | |
| ``ca+t`` will match ``'cat'`` (1 ``'a'``), ``'caaat'`` (3 ``'a'``\ s), but won't | |
| match ``'ct'``. | |
| There are two more repeating qualifiers. The question mark character, ``?``, | |
| matches either once or zero times; you can think of it as marking something as | |
| being optional. For example, ``home-?brew`` matches either ``'homebrew'`` or | |
| ``'home-brew'``. | |
| The most complicated repeated qualifier is ``{m,n}``, where *m* and *n* are | |
| decimal integers. This qualifier means there must be at least *m* repetitions, | |
| and at most *n*. For example, ``a/{1,3}b`` will match ``'a/b'``, ``'a//b'``, and | |
| ``'a///b'``. It won't match ``'ab'``, which has no slashes, or ``'a////b'``, which | |
| has four. | |
| You can omit either *m* or *n*; in that case, a reasonable value is assumed for | |
| the missing value. Omitting *m* is interpreted as a lower limit of 0, while | |
| omitting *n* results in an upper bound of infinity. | |
| Readers of a reductionist bent may notice that the three other qualifiers can | |
| all be expressed using this notation. ``{0,}`` is the same as ``*``, ``{1,}`` | |
| is equivalent to ``+``, and ``{0,1}`` is the same as ``?``. It's better to use | |
| ``*``, ``+``, or ``?`` when you can, simply because they're shorter and easier | |
| to read. | |
| Using Regular Expressions | |
| ========================= | |
| Now that we've looked at some simple regular expressions, how do we actually use | |
| them in Python? The :mod:`re` module provides an interface to the regular | |
| expression engine, allowing you to compile REs into objects and then perform | |
| matches with them. | |
| Compiling Regular Expressions | |
| ----------------------------- | |
| Regular expressions are compiled into pattern objects, which have | |
| methods for various operations such as searching for pattern matches or | |
| performing string substitutions. :: | |
| >>> import re | |
| >>> p = re.compile('ab*') | |
| >>> p | |
| re.compile('ab*') | |
| :func:`re.compile` also accepts an optional *flags* argument, used to enable | |
| various special features and syntax variations. We'll go over the available | |
| settings later, but for now a single example will do:: | |
| >>> p = re.compile('ab*', re.IGNORECASE) | |
| The RE is passed to :func:`re.compile` as a string. REs are handled as strings | |
| because regular expressions aren't part of the core Python language, and no | |
| special syntax was created for expressing them. (There are applications that | |
| don't need REs at all, so there's no need to bloat the language specification by | |
| including them.) Instead, the :mod:`re` module is simply a C extension module | |
| included with Python, just like the :mod:`socket` or :mod:`zlib` modules. | |
| Putting REs in strings keeps the Python language simpler, but has one | |
| disadvantage which is the topic of the next section. | |
| .. _the-backslash-plague: | |
| The Backslash Plague | |
| -------------------- | |
| As stated earlier, regular expressions use the backslash character (``'\'``) to | |
| indicate special forms or to allow special characters to be used without | |
| invoking their special meaning. This conflicts with Python's usage of the same | |
| character for the same purpose in string literals. | |
| Let's say you want to write a RE that matches the string ``\section``, which | |
| might be found in a LaTeX file. To figure out what to write in the program | |
| code, start with the desired string to be matched. Next, you must escape any | |
| backslashes and other metacharacters by preceding them with a backslash, | |
| resulting in the string ``\\section``. The resulting string that must be passed | |
| to :func:`re.compile` must be ``\\section``. However, to express this as a | |
| Python string literal, both backslashes must be escaped *again*. | |
| +-------------------+------------------------------------------+ | |
| | Characters | Stage | | |
| +===================+==========================================+ | |
| | ``\section`` | Text string to be matched | | |
| +-------------------+------------------------------------------+ | |
| | ``\\section`` | Escaped backslash for :func:`re.compile` | | |
| +-------------------+------------------------------------------+ | |
| | ``"\\\\section"`` | Escaped backslashes for a string literal | | |
| +-------------------+------------------------------------------+ | |
| In short, to match a literal backslash, one has to write ``'\\\\'`` as the RE | |
| string, because the regular expression must be ``\\``, and each backslash must | |
| be expressed as ``\\`` inside a regular Python string literal. In REs that | |
| feature backslashes repeatedly, this leads to lots of repeated backslashes and | |
| makes the resulting strings difficult to understand. | |
| The solution is to use Python's raw string notation for regular expressions; | |
| backslashes are not handled in any special way in a string literal prefixed with | |
| ``'r'``, so ``r"\n"`` is a two-character string containing ``'\'`` and ``'n'``, | |
| while ``"\n"`` is a one-character string containing a newline. Regular | |
| expressions will often be written in Python code using this raw string notation. | |
| In addition, special escape sequences that are valid in regular expressions, | |
| but not valid as Python string literals, now result in a | |
| :exc:`DeprecationWarning` and will eventually become a :exc:`SyntaxError`, | |
| which means the sequences will be invalid if raw string notation or escaping | |
| the backslashes isn't used. | |
| +-------------------+------------------+ | |
| | Regular String | Raw string | | |
| +===================+==================+ | |
| | ``"ab*"`` | ``r"ab*"`` | | |
| +-------------------+------------------+ | |
| | ``"\\\\section"`` | ``r"\\section"`` | | |
| +-------------------+------------------+ | |
| | ``"\\w+\\s+\\1"`` | ``r"\w+\s+\1"`` | | |
| +-------------------+------------------+ | |
| Performing Matches | |
| ------------------ | |
| Once you have an object representing a compiled regular expression, what do you | |
| do with it? Pattern objects have several methods and attributes. | |
| Only the most significant ones will be covered here; consult the :mod:`re` docs | |
| for a complete listing. | |
| +------------------+-----------------------------------------------+ | |
| | Method/Attribute | Purpose | | |
| +==================+===============================================+ | |
| | ``match()`` | Determine if the RE matches at the beginning | | |
| | | of the string. | | |
| +------------------+-----------------------------------------------+ | |
| | ``search()`` | Scan through a string, looking for any | | |
| | | location where this RE matches. | | |
| +------------------+-----------------------------------------------+ | |
| | ``findall()`` | Find all substrings where the RE matches, and | | |
| | | returns them as a list. | | |
| +------------------+-----------------------------------------------+ | |
| | ``finditer()`` | Find all substrings where the RE matches, and | | |
| | | returns them as an :term:`iterator`. | | |
| +------------------+-----------------------------------------------+ | |
| :meth:`~re.Pattern.match` and :meth:`~re.Pattern.search` return ``None`` if no match can be found. If | |
| they're successful, a :ref:`match object <match-objects>` instance is returned, | |
| containing information about the match: where it starts and ends, the substring | |
| it matched, and more. | |
| You can learn about this by interactively experimenting with the :mod:`re` | |
| module. If you have :mod:`tkinter` available, you may also want to look at | |
| :source:`Tools/demo/redemo.py`, a demonstration program included with the | |
| Python distribution. It allows you to enter REs and strings, and displays | |
| whether the RE matches or fails. :file:`redemo.py` can be quite useful when | |
| trying to debug a complicated RE. | |
| This HOWTO uses the standard Python interpreter for its examples. First, run the | |
| Python interpreter, import the :mod:`re` module, and compile a RE:: | |
| >>> import re | |
| >>> p = re.compile('[a-z]+') | |
| >>> p | |
| re.compile('[a-z]+') | |
| Now, you can try matching various strings against the RE ``[a-z]+``. An empty | |
| string shouldn't match at all, since ``+`` means 'one or more repetitions'. | |
| :meth:`~re.Pattern.match` should return ``None`` in this case, which will cause the | |
| interpreter to print no output. You can explicitly print the result of | |
| :meth:`!match` to make this clear. :: | |
| >>> p.match("") | |
| >>> print(p.match("")) | |
| None | |
| Now, let's try it on a string that it should match, such as ``tempo``. In this | |
| case, :meth:`~re.Pattern.match` will return a :ref:`match object <match-objects>`, so you | |
| should store the result in a variable for later use. :: | |
| >>> m = p.match('tempo') | |
| >>> m | |
| <re.Match object; span=(0, 5), match='tempo'> | |
| Now you can query the :ref:`match object <match-objects>` for information | |
| about the matching string. Match object instances | |
| also have several methods and attributes; the most important ones are: | |
| +------------------+--------------------------------------------+ | |
| | Method/Attribute | Purpose | | |
| +==================+============================================+ | |
| | ``group()`` | Return the string matched by the RE | | |
| +------------------+--------------------------------------------+ | |
| | ``start()`` | Return the starting position of the match | | |
| +------------------+--------------------------------------------+ | |
| | ``end()`` | Return the ending position of the match | | |
| +------------------+--------------------------------------------+ | |
| | ``span()`` | Return a tuple containing the (start, end) | | |
| | | positions of the match | | |
| +------------------+--------------------------------------------+ | |
| Trying these methods will soon clarify their meaning:: | |
| >>> m.group() | |
| 'tempo' | |
| >>> m.start(), m.end() | |
| (0, 5) | |
| >>> m.span() | |
| (0, 5) | |
| :meth:`~re.Match.group` returns the substring that was matched by the RE. :meth:`~re.Match.start` | |
| and :meth:`~re.Match.end` return the starting and ending index of the match. :meth:`~re.Match.span` | |
| returns both start and end indexes in a single tuple. Since the :meth:`~re.Pattern.match` | |
| method only checks if the RE matches at the start of a string, :meth:`!start` | |
| will always be zero. However, the :meth:`~re.Pattern.search` method of patterns | |
| scans through the string, so the match may not start at zero in that | |
| case. :: | |
| >>> print(p.match('::: message')) | |
| None | |
| >>> m = p.search('::: message'); print(m) | |
| <re.Match object; span=(4, 11), match='message'> | |
| >>> m.group() | |
| 'message' | |
| >>> m.span() | |
| (4, 11) | |
| In actual programs, the most common style is to store the | |
| :ref:`match object <match-objects>` in a variable, and then check if it was | |
| ``None``. This usually looks like:: | |
| p = re.compile( ... ) | |
| m = p.match( 'string goes here' ) | |
| if m: | |
| print('Match found: ', m.group()) | |
| else: | |
| print('No match') | |
| Two pattern methods return all of the matches for a pattern. | |
| :meth:`~re.Pattern.findall` returns a list of matching strings:: | |
| >>> p = re.compile(r'\d+') | |
| >>> p.findall('12 drummers drumming, 11 pipers piping, 10 lords a-leaping') | |
| ['12', '11', '10'] | |
| The ``r`` prefix, making the literal a raw string literal, is needed in this | |
| example because escape sequences in a normal "cooked" string literal that are | |
| not recognized by Python, as opposed to regular expressions, now result in a | |
| :exc:`DeprecationWarning` and will eventually become a :exc:`SyntaxError`. See | |
| :ref:`the-backslash-plague`. | |
| :meth:`~re.Pattern.findall` has to create the entire list before it can be returned as the | |
| result. The :meth:`~re.Pattern.finditer` method returns a sequence of | |
| :ref:`match object <match-objects>` instances as an :term:`iterator`:: | |
| >>> iterator = p.finditer('12 drummers drumming, 11 ... 10 ...') | |
| >>> iterator #doctest: +ELLIPSIS | |
| <callable_iterator object at 0x...> | |
| >>> for match in iterator: | |
| ... print(match.span()) | |
| ... | |
| (0, 2) | |
| (22, 24) | |
| (29, 31) | |
| Module-Level Functions | |
| ---------------------- | |
| You don't have to create a pattern object and call its methods; the | |
| :mod:`re` module also provides top-level functions called :func:`~re.match`, | |
| :func:`~re.search`, :func:`~re.findall`, :func:`~re.sub`, and so forth. These functions | |
| take the same arguments as the corresponding pattern method with | |
| the RE string added as the first argument, and still return either ``None`` or a | |
| :ref:`match object <match-objects>` instance. :: | |
| >>> print(re.match(r'From\s+', 'Fromage amk')) | |
| None | |
| >>> re.match(r'From\s+', 'From amk Thu May 14 19:12:10 1998') #doctest: +ELLIPSIS | |
| <re.Match object; span=(0, 5), match='From '> | |
| Under the hood, these functions simply create a pattern object for you | |
| and call the appropriate method on it. They also store the compiled | |
| object in a cache, so future calls using the same RE won't need to | |
| parse the pattern again and again. | |
| Should you use these module-level functions, or should you get the | |
| pattern and call its methods yourself? If you're accessing a regex | |
| within a loop, pre-compiling it will save a few function calls. | |
| Outside of loops, there's not much difference thanks to the internal | |
| cache. | |
| Compilation Flags | |
| ----------------- | |
| Compilation flags let you modify some aspects of how regular expressions work. | |
| Flags are available in the :mod:`re` module under two names, a long name such as | |
| :const:`IGNORECASE` and a short, one-letter form such as :const:`I`. (If you're | |
| familiar with Perl's pattern modifiers, the one-letter forms use the same | |
| letters; the short form of :const:`re.VERBOSE` is :const:`re.X`, for example.) | |
| Multiple flags can be specified by bitwise OR-ing them; ``re.I | re.M`` sets | |
| both the :const:`I` and :const:`M` flags, for example. | |
| Here's a table of the available flags, followed by a more detailed explanation | |
| of each one. | |
| +---------------------------------+--------------------------------------------+ | |
| | Flag | Meaning | | |
| +=================================+============================================+ | |
| | :const:`ASCII`, :const:`A` | Makes several escapes like ``\w``, ``\b``, | | |
| | | ``\s`` and ``\d`` match only on ASCII | | |
| | | characters with the respective property. | | |
| +---------------------------------+--------------------------------------------+ | |
| | :const:`DOTALL`, :const:`S` | Make ``.`` match any character, including | | |
| | | newlines. | | |
| +---------------------------------+--------------------------------------------+ | |
| | :const:`IGNORECASE`, :const:`I` | Do case-insensitive matches. | | |
| +---------------------------------+--------------------------------------------+ | |
| | :const:`LOCALE`, :const:`L` | Do a locale-aware match. | | |
| +---------------------------------+--------------------------------------------+ | |
| | :const:`MULTILINE`, :const:`M` | Multi-line matching, affecting ``^`` and | | |
| | | ``$``. | | |
| +---------------------------------+--------------------------------------------+ | |
| | :const:`VERBOSE`, :const:`X` | Enable verbose REs, which can be organized | | |
| | (for 'extended') | more cleanly and understandably. | | |
| +---------------------------------+--------------------------------------------+ | |
| .. data:: I | |
| IGNORECASE | |
| :noindex: | |
| Perform case-insensitive matching; character class and literal strings will | |
| match letters by ignoring case. For example, ``[A-Z]`` will match lowercase | |
| letters, too. Full Unicode matching also works unless the :const:`ASCII` | |
| flag is used to disable non-ASCII matches. When the Unicode patterns | |
| ``[a-z]`` or ``[A-Z]`` are used in combination with the :const:`IGNORECASE` | |
| flag, they will match the 52 ASCII letters and 4 additional non-ASCII | |
| letters: 'İ' (U+0130, Latin capital letter I with dot above), 'ı' (U+0131, | |
| Latin small letter dotless i), 'Å¿' (U+017F, Latin small letter long s) and | |
| 'K' (U+212A, Kelvin sign). ``Spam`` will match ``'Spam'``, ``'spam'``, | |
| ``'spAM'``, or ``'ſpam'`` (the latter is matched only in Unicode mode). | |
| This lowercasing doesn't take the current locale into account; | |
| it will if you also set the :const:`LOCALE` flag. | |
| .. data:: L | |
| LOCALE | |
| :noindex: | |
| Make ``\w``, ``\W``, ``\b``, ``\B`` and case-insensitive matching dependent | |
| on the current locale instead of the Unicode database. | |
| Locales are a feature of the C library intended to help in writing programs | |
| that take account of language differences. For example, if you're | |
| processing encoded French text, you'd want to be able to write ``\w+`` to | |
| match words, but ``\w`` only matches the character class ``[A-Za-z]`` in | |
| bytes patterns; it won't match bytes corresponding to ``é`` or ``ç``. | |
| If your system is configured properly and a French locale is selected, | |
| certain C functions will tell the program that the byte corresponding to | |
| ``é`` should also be considered a letter. | |
| Setting the :const:`LOCALE` flag when compiling a regular expression will cause | |
| the resulting compiled object to use these C functions for ``\w``; this is | |
| slower, but also enables ``\w+`` to match French words as you'd expect. | |
| The use of this flag is discouraged in Python 3 as the locale mechanism | |
| is very unreliable, it only handles one "culture" at a time, and it only | |
| works with 8-bit locales. Unicode matching is already enabled by default | |
| in Python 3 for Unicode (str) patterns, and it is able to handle different | |
| locales/languages. | |
| .. data:: M | |
| MULTILINE | |
| :noindex: | |
| (``^`` and ``$`` haven't been explained yet; they'll be introduced in section | |
| :ref:`more-metacharacters`.) | |
| Usually ``^`` matches only at the beginning of the string, and ``$`` matches | |
| only at the end of the string and immediately before the newline (if any) at the | |
| end of the string. When this flag is specified, ``^`` matches at the beginning | |
| of the string and at the beginning of each line within the string, immediately | |
| following each newline. Similarly, the ``$`` metacharacter matches either at | |
| the end of the string and at the end of each line (immediately preceding each | |
| newline). | |
| .. data:: S | |
| DOTALL | |
| :noindex: | |
| Makes the ``'.'`` special character match any character at all, including a | |
| newline; without this flag, ``'.'`` will match anything *except* a newline. | |
| .. data:: A | |
| ASCII | |
| :noindex: | |
| Make ``\w``, ``\W``, ``\b``, ``\B``, ``\s`` and ``\S`` perform ASCII-only | |
| matching instead of full Unicode matching. This is only meaningful for | |
| Unicode patterns, and is ignored for byte patterns. | |
| .. data:: X | |
| VERBOSE | |
| :noindex: | |
| This flag allows you to write regular expressions that are more readable by | |
| granting you more flexibility in how you can format them. When this flag has | |
| been specified, whitespace within the RE string is ignored, except when the | |
| whitespace is in a character class or preceded by an unescaped backslash; this | |
| lets you organize and indent the RE more clearly. This flag also lets you put | |
| comments within a RE that will be ignored by the engine; comments are marked by | |
| a ``'#'`` that's neither in a character class or preceded by an unescaped | |
| backslash. | |
| For example, here's a RE that uses :const:`re.VERBOSE`; see how much easier it | |
| is to read? :: | |
| charref = re.compile(r""" | |
| &[#] # Start of a numeric entity reference | |
| ( | |
| 0[0-7]+ # Octal form | |
| | [0-9]+ # Decimal form | |
| | x[0-9a-fA-F]+ # Hexadecimal form | |
| ) | |
| ; # Trailing semicolon | |
| """, re.VERBOSE) | |
| Without the verbose setting, the RE would look like this:: | |
| charref = re.compile("&#(0[0-7]+" | |
| "|[0-9]+" | |
| "|x[0-9a-fA-F]+);") | |
| In the above example, Python's automatic concatenation of string literals has | |
| been used to break up the RE into smaller pieces, but it's still more difficult | |
| to understand than the version using :const:`re.VERBOSE`. | |
| More Pattern Power | |
| ================== | |
| So far we've only covered a part of the features of regular expressions. In | |
| this section, we'll cover some new metacharacters, and how to use groups to | |
| retrieve portions of the text that was matched. | |
| .. _more-metacharacters: | |
| More Metacharacters | |
| ------------------- | |
| There are some metacharacters that we haven't covered yet. Most of them will be | |
| covered in this section. | |
| Some of the remaining metacharacters to be discussed are :dfn:`zero-width | |
| assertions`. They don't cause the engine to advance through the string; | |
| instead, they consume no characters at all, and simply succeed or fail. For | |
| example, ``\b`` is an assertion that the current position is located at a word | |
| boundary; the position isn't changed by the ``\b`` at all. This means that | |
| zero-width assertions should never be repeated, because if they match once at a | |
| given location, they can obviously be matched an infinite number of times. | |
| ``|`` | |
| Alternation, or the "or" operator. If *A* and *B* are regular expressions, | |
| ``A|B`` will match any string that matches either *A* or *B*. ``|`` has very | |
| low precedence in order to make it work reasonably when you're alternating | |
| multi-character strings. ``Crow|Servo`` will match either ``'Crow'`` or ``'Servo'``, | |
| not ``'Cro'``, a ``'w'`` or an ``'S'``, and ``'ervo'``. | |
| To match a literal ``'|'``, use ``\|``, or enclose it inside a character class, | |
| as in ``[|]``. | |
| ``^`` | |
| Matches at the beginning of lines. Unless the :const:`MULTILINE` flag has been | |
| set, this will only match at the beginning of the string. In :const:`MULTILINE` | |
| mode, this also matches immediately after each newline within the string. | |
| For example, if you wish to match the word ``From`` only at the beginning of a | |
| line, the RE to use is ``^From``. :: | |
| >>> print(re.search('^From', 'From Here to Eternity')) #doctest: +ELLIPSIS | |
| <re.Match object; span=(0, 4), match='From'> | |
| >>> print(re.search('^From', 'Reciting From Memory')) | |
| None | |
| To match a literal ``'^'``, use ``\^``. | |
| ``$`` | |
| Matches at the end of a line, which is defined as either the end of the string, | |
| or any location followed by a newline character. :: | |
| >>> print(re.search('}$', '{block}')) #doctest: +ELLIPSIS | |
| <re.Match object; span=(6, 7), match='}'> | |
| >>> print(re.search('}$', '{block} ')) | |
| None | |
| >>> print(re.search('}$', '{block}\n')) #doctest: +ELLIPSIS | |
| <re.Match object; span=(6, 7), match='}'> | |
| To match a literal ``'$'``, use ``\$`` or enclose it inside a character class, | |
| as in ``[$]``. | |
| ``\A`` | |
| Matches only at the start of the string. When not in :const:`MULTILINE` mode, | |
| ``\A`` and ``^`` are effectively the same. In :const:`MULTILINE` mode, they're | |
| different: ``\A`` still matches only at the beginning of the string, but ``^`` | |
| may match at any location inside the string that follows a newline character. | |
| ``\Z`` | |
| Matches only at the end of the string. | |
| ``\b`` | |
| Word boundary. This is a zero-width assertion that matches only at the | |
| beginning or end of a word. A word is defined as a sequence of alphanumeric | |
| characters, so the end of a word is indicated by whitespace or a | |
| non-alphanumeric character. | |
| The following example matches ``class`` only when it's a complete word; it won't | |
| match when it's contained inside another word. :: | |
| >>> p = re.compile(r'\bclass\b') | |
| >>> print(p.search('no class at all')) | |
| <re.Match object; span=(3, 8), match='class'> | |
| >>> print(p.search('the declassified algorithm')) | |
| None | |
| >>> print(p.search('one subclass is')) | |
| None | |
| There are two subtleties you should remember when using this special sequence. | |
| First, this is the worst collision between Python's string literals and regular | |
| expression sequences. In Python's string literals, ``\b`` is the backspace | |
| character, ASCII value 8. If you're not using raw strings, then Python will | |
| convert the ``\b`` to a backspace, and your RE won't match as you expect it to. | |
| The following example looks the same as our previous RE, but omits the ``'r'`` | |
| in front of the RE string. :: | |
| >>> p = re.compile('\bclass\b') | |
| >>> print(p.search('no class at all')) | |
| None | |
| >>> print(p.search('\b' + 'class' + '\b')) | |
| <re.Match object; span=(0, 7), match='\x08class\x08'> | |
| Second, inside a character class, where there's no use for this assertion, | |
| ``\b`` represents the backspace character, for compatibility with Python's | |
| string literals. | |
| ``\B`` | |
| Another zero-width assertion, this is the opposite of ``\b``, only matching when | |
| the current position is not at a word boundary. | |
| Grouping | |
| -------- | |
| Frequently you need to obtain more information than just whether the RE matched | |
| or not. Regular expressions are often used to dissect strings by writing a RE | |
| divided into several subgroups which match different components of interest. | |
| For example, an RFC-822 header line is divided into a header name and a value, | |
| separated by a ``':'``, like this: | |
| .. code-block:: none | |
| From: author@example.com | |
| User-Agent: Thunderbird 1.5.0.9 (X11/20061227) | |
| MIME-Version: 1.0 | |
| To: editor@example.com | |
| This can be handled by writing a regular expression which matches an entire | |
| header line, and has one group which matches the header name, and another group | |
| which matches the header's value. | |
| Groups are marked by the ``'('``, ``')'`` metacharacters. ``'('`` and ``')'`` | |
| have much the same meaning as they do in mathematical expressions; they group | |
| together the expressions contained inside them, and you can repeat the contents | |
| of a group with a repeating qualifier, such as ``*``, ``+``, ``?``, or | |
| ``{m,n}``. For example, ``(ab)*`` will match zero or more repetitions of | |
| ``ab``. :: | |
| >>> p = re.compile('(ab)*') | |
| >>> print(p.match('ababababab').span()) | |
| (0, 10) | |
| Groups indicated with ``'('``, ``')'`` also capture the starting and ending | |
| index of the text that they match; this can be retrieved by passing an argument | |
| to :meth:`~re.Match.group`, :meth:`~re.Match.start`, :meth:`~re.Match.end`, and | |
| :meth:`~re.Match.span`. Groups are | |
| numbered starting with 0. Group 0 is always present; it's the whole RE, so | |
| :ref:`match object <match-objects>` methods all have group 0 as their default | |
| argument. Later we'll see how to express groups that don't capture the span | |
| of text that they match. :: | |
| >>> p = re.compile('(a)b') | |
| >>> m = p.match('ab') | |
| >>> m.group() | |
| 'ab' | |
| >>> m.group(0) | |
| 'ab' | |
| Subgroups are numbered from left to right, from 1 upward. Groups can be nested; | |
| to determine the number, just count the opening parenthesis characters, going | |
| from left to right. :: | |
| >>> p = re.compile('(a(b)c)d') | |
| >>> m = p.match('abcd') | |
| >>> m.group(0) | |
| 'abcd' | |
| >>> m.group(1) | |
| 'abc' | |
| >>> m.group(2) | |
| 'b' | |
| :meth:`~re.Match.group` can be passed multiple group numbers at a time, in which case it | |
| will return a tuple containing the corresponding values for those groups. :: | |
| >>> m.group(2,1,2) | |
| ('b', 'abc', 'b') | |
| The :meth:`~re.Match.groups` method returns a tuple containing the strings for all the | |
| subgroups, from 1 up to however many there are. :: | |
| >>> m.groups() | |
| ('abc', 'b') | |
| Backreferences in a pattern allow you to specify that the contents of an earlier | |
| capturing group must also be found at the current location in the string. For | |
| example, ``\1`` will succeed if the exact contents of group 1 can be found at | |
| the current position, and fails otherwise. Remember that Python's string | |
| literals also use a backslash followed by numbers to allow including arbitrary | |
| characters in a string, so be sure to use a raw string when incorporating | |
| backreferences in a RE. | |
| For example, the following RE detects doubled words in a string. :: | |
| >>> p = re.compile(r'\b(\w+)\s+\1\b') | |
| >>> p.search('Paris in the the spring').group() | |
| 'the the' | |
| Backreferences like this aren't often useful for just searching through a string | |
| --- there are few text formats which repeat data in this way --- but you'll soon | |
| find out that they're *very* useful when performing string substitutions. | |
| Non-capturing and Named Groups | |
| ------------------------------ | |
| Elaborate REs may use many groups, both to capture substrings of interest, and | |
| to group and structure the RE itself. In complex REs, it becomes difficult to | |
| keep track of the group numbers. There are two features which help with this | |
| problem. Both of them use a common syntax for regular expression extensions, so | |
| we'll look at that first. | |
| Perl 5 is well known for its powerful additions to standard regular expressions. | |
| For these new features the Perl developers couldn't choose new single-keystroke metacharacters | |
| or new special sequences beginning with ``\`` without making Perl's regular | |
| expressions confusingly different from standard REs. If they chose ``&`` as a | |
| new metacharacter, for example, old expressions would be assuming that ``&`` was | |
| a regular character and wouldn't have escaped it by writing ``\&`` or ``[&]``. | |
| The solution chosen by the Perl developers was to use ``(?...)`` as the | |
| extension syntax. ``?`` immediately after a parenthesis was a syntax error | |
| because the ``?`` would have nothing to repeat, so this didn't introduce any | |
| compatibility problems. The characters immediately after the ``?`` indicate | |
| what extension is being used, so ``(?=foo)`` is one thing (a positive lookahead | |
| assertion) and ``(?:foo)`` is something else (a non-capturing group containing | |
| the subexpression ``foo``). | |
| Python supports several of Perl's extensions and adds an extension | |
| syntax to Perl's extension syntax. If the first character after the | |
| question mark is a ``P``, you know that it's an extension that's | |
| specific to Python. | |
| Now that we've looked at the general extension syntax, we can return | |
| to the features that simplify working with groups in complex REs. | |
| Sometimes you'll want to use a group to denote a part of a regular expression, | |
| but aren't interested in retrieving the group's contents. You can make this fact | |
| explicit by using a non-capturing group: ``(?:...)``, where you can replace the | |
| ``...`` with any other regular expression. :: | |
| >>> m = re.match("([abc])+", "abc") | |
| >>> m.groups() | |
| ('c',) | |
| >>> m = re.match("(?:[abc])+", "abc") | |
| >>> m.groups() | |
| () | |
| Except for the fact that you can't retrieve the contents of what the group | |
| matched, a non-capturing group behaves exactly the same as a capturing group; | |
| you can put anything inside it, repeat it with a repetition metacharacter such | |
| as ``*``, and nest it within other groups (capturing or non-capturing). | |
| ``(?:...)`` is particularly useful when modifying an existing pattern, since you | |
| can add new groups without changing how all the other groups are numbered. It | |
| should be mentioned that there's no performance difference in searching between | |
| capturing and non-capturing groups; neither form is any faster than the other. | |
| A more significant feature is named groups: instead of referring to them by | |
| numbers, groups can be referenced by a name. | |
| The syntax for a named group is one of the Python-specific extensions: | |
| ``(?P<name>...)``. *name* is, obviously, the name of the group. Named groups | |
| behave exactly like capturing groups, and additionally associate a name | |
| with a group. The :ref:`match object <match-objects>` methods that deal with | |
| capturing groups all accept either integers that refer to the group by number | |
| or strings that contain the desired group's name. Named groups are still | |
| given numbers, so you can retrieve information about a group in two ways:: | |
| >>> p = re.compile(r'(?P<word>\b\w+\b)') | |
| >>> m = p.search( '(((( Lots of punctuation )))' ) | |
| >>> m.group('word') | |
| 'Lots' | |
| >>> m.group(1) | |
| 'Lots' | |
| Additionally, you can retrieve named groups as a dictionary with | |
| :meth:`~re.Match.groupdict`:: | |
| >>> m = re.match(r'(?P<first>\w+) (?P<last>\w+)', 'Jane Doe') | |
| >>> m.groupdict() | |
| {'first': 'Jane', 'last': 'Doe'} | |
| Named groups are handy because they let you use easily-remembered names, instead | |
| of having to remember numbers. Here's an example RE from the :mod:`imaplib` | |
| module:: | |
| InternalDate = re.compile(r'INTERNALDATE "' | |
| r'(?P<day>[ 123][0-9])-(?P<mon>[A-Z][a-z][a-z])-' | |
| r'(?P<year>[0-9][0-9][0-9][0-9])' | |
| r' (?P<hour>[0-9][0-9]):(?P<min>[0-9][0-9]):(?P<sec>[0-9][0-9])' | |
| r' (?P<zonen>[-+])(?P<zoneh>[0-9][0-9])(?P<zonem>[0-9][0-9])' | |
| r'"') | |
| It's obviously much easier to retrieve ``m.group('zonem')``, instead of having | |
| to remember to retrieve group 9. | |
| The syntax for backreferences in an expression such as ``(...)\1`` refers to the | |
| number of the group. There's naturally a variant that uses the group name | |
| instead of the number. This is another Python extension: ``(?P=name)`` indicates | |
| that the contents of the group called *name* should again be matched at the | |
| current point. The regular expression for finding doubled words, | |
| ``\b(\w+)\s+\1\b`` can also be written as ``\b(?P<word>\w+)\s+(?P=word)\b``:: | |
| >>> p = re.compile(r'\b(?P<word>\w+)\s+(?P=word)\b') | |
| >>> p.search('Paris in the the spring').group() | |
| 'the the' | |
| Lookahead Assertions | |
| -------------------- | |
| Another zero-width assertion is the lookahead assertion. Lookahead assertions | |
| are available in both positive and negative form, and look like this: | |
| ``(?=...)`` | |
| Positive lookahead assertion. This succeeds if the contained regular | |
| expression, represented here by ``...``, successfully matches at the current | |
| location, and fails otherwise. But, once the contained expression has been | |
| tried, the matching engine doesn't advance at all; the rest of the pattern is | |
| tried right where the assertion started. | |
| ``(?!...)`` | |
| Negative lookahead assertion. This is the opposite of the positive assertion; | |
| it succeeds if the contained expression *doesn't* match at the current position | |
| in the string. | |
| To make this concrete, let's look at a case where a lookahead is useful. | |
| Consider a simple pattern to match a filename and split it apart into a base | |
| name and an extension, separated by a ``.``. For example, in ``news.rc``, | |
| ``news`` is the base name, and ``rc`` is the filename's extension. | |
| The pattern to match this is quite simple: | |
| ``.*[.].*$`` | |
| Notice that the ``.`` needs to be treated specially because it's a | |
| metacharacter, so it's inside a character class to only match that | |
| specific character. Also notice the trailing ``$``; this is added to | |
| ensure that all the rest of the string must be included in the | |
| extension. This regular expression matches ``foo.bar`` and | |
| ``autoexec.bat`` and ``sendmail.cf`` and ``printers.conf``. | |
| Now, consider complicating the problem a bit; what if you want to match | |
| filenames where the extension is not ``bat``? Some incorrect attempts: | |
| ``.*[.][^b].*$`` The first attempt above tries to exclude ``bat`` by requiring | |
| that the first character of the extension is not a ``b``. This is wrong, | |
| because the pattern also doesn't match ``foo.bar``. | |
| ``.*[.]([^b]..|.[^a].|..[^t])$`` | |
| The expression gets messier when you try to patch up the first solution by | |
| requiring one of the following cases to match: the first character of the | |
| extension isn't ``b``; the second character isn't ``a``; or the third character | |
| isn't ``t``. This accepts ``foo.bar`` and rejects ``autoexec.bat``, but it | |
| requires a three-letter extension and won't accept a filename with a two-letter | |
| extension such as ``sendmail.cf``. We'll complicate the pattern again in an | |
| effort to fix it. | |
| ``.*[.]([^b].?.?|.[^a]?.?|..?[^t]?)$`` | |
| In the third attempt, the second and third letters are all made optional in | |
| order to allow matching extensions shorter than three characters, such as | |
| ``sendmail.cf``. | |
| The pattern's getting really complicated now, which makes it hard to read and | |
| understand. Worse, if the problem changes and you want to exclude both ``bat`` | |
| and ``exe`` as extensions, the pattern would get even more complicated and | |
| confusing. | |
| A negative lookahead cuts through all this confusion: | |
| ``.*[.](?!bat$)[^.]*$`` The negative lookahead means: if the expression ``bat`` | |
| doesn't match at this point, try the rest of the pattern; if ``bat$`` does | |
| match, the whole pattern will fail. The trailing ``$`` is required to ensure | |
| that something like ``sample.batch``, where the extension only starts with | |
| ``bat``, will be allowed. The ``[^.]*`` makes sure that the pattern works | |
| when there are multiple dots in the filename. | |
| Excluding another filename extension is now easy; simply add it as an | |
| alternative inside the assertion. The following pattern excludes filenames that | |
| end in either ``bat`` or ``exe``: | |
| ``.*[.](?!bat$|exe$)[^.]*$`` | |
| Modifying Strings | |
| ================= | |
| Up to this point, we've simply performed searches against a static string. | |
| Regular expressions are also commonly used to modify strings in various ways, | |
| using the following pattern methods: | |
| +------------------+-----------------------------------------------+ | |
| | Method/Attribute | Purpose | | |
| +==================+===============================================+ | |
| | ``split()`` | Split the string into a list, splitting it | | |
| | | wherever the RE matches | | |
| +------------------+-----------------------------------------------+ | |
| | ``sub()`` | Find all substrings where the RE matches, and | | |
| | | replace them with a different string | | |
| +------------------+-----------------------------------------------+ | |
| | ``subn()`` | Does the same thing as :meth:`!sub`, but | | |
| | | returns the new string and the number of | | |
| | | replacements | | |
| +------------------+-----------------------------------------------+ | |
| Splitting Strings | |
| ----------------- | |
| The :meth:`~re.Pattern.split` method of a pattern splits a string apart | |
| wherever the RE matches, returning a list of the pieces. It's similar to the | |
| :meth:`~str.split` method of strings but provides much more generality in the | |
| delimiters that you can split by; string :meth:`!split` only supports splitting by | |
| whitespace or by a fixed string. As you'd expect, there's a module-level | |
| :func:`re.split` function, too. | |
| .. method:: .split(string [, maxsplit=0]) | |
| :noindex: | |
| Split *string* by the matches of the regular expression. If capturing | |
| parentheses are used in the RE, then their contents will also be returned as | |
| part of the resulting list. If *maxsplit* is nonzero, at most *maxsplit* splits | |
| are performed. | |
| You can limit the number of splits made, by passing a value for *maxsplit*. | |
| When *maxsplit* is nonzero, at most *maxsplit* splits will be made, and the | |
| remainder of the string is returned as the final element of the list. In the | |
| following example, the delimiter is any sequence of non-alphanumeric characters. | |
| :: | |
| >>> p = re.compile(r'\W+') | |
| >>> p.split('This is a test, short and sweet, of split().') | |
| ['This', 'is', 'a', 'test', 'short', 'and', 'sweet', 'of', 'split', ''] | |
| >>> p.split('This is a test, short and sweet, of split().', 3) | |
| ['This', 'is', 'a', 'test, short and sweet, of split().'] | |
| Sometimes you're not only interested in what the text between delimiters is, but | |
| also need to know what the delimiter was. If capturing parentheses are used in | |
| the RE, then their values are also returned as part of the list. Compare the | |
| following calls:: | |
| >>> p = re.compile(r'\W+') | |
| >>> p2 = re.compile(r'(\W+)') | |
| >>> p.split('This... is a test.') | |
| ['This', 'is', 'a', 'test', ''] | |
| >>> p2.split('This... is a test.') | |
| ['This', '... ', 'is', ' ', 'a', ' ', 'test', '.', ''] | |
| The module-level function :func:`re.split` adds the RE to be used as the first | |
| argument, but is otherwise the same. :: | |
| >>> re.split(r'[\W]+', 'Words, words, words.') | |
| ['Words', 'words', 'words', ''] | |
| >>> re.split(r'([\W]+)', 'Words, words, words.') | |
| ['Words', ', ', 'words', ', ', 'words', '.', ''] | |
| >>> re.split(r'[\W]+', 'Words, words, words.', 1) | |
| ['Words', 'words, words.'] | |
| Search and Replace | |
| ------------------ | |
| Another common task is to find all the matches for a pattern, and replace them | |
| with a different string. The :meth:`~re.Pattern.sub` method takes a replacement value, | |
| which can be either a string or a function, and the string to be processed. | |
| .. method:: .sub(replacement, string[, count=0]) | |
| :noindex: | |
| Returns the string obtained by replacing the leftmost non-overlapping | |
| occurrences of the RE in *string* by the replacement *replacement*. If the | |
| pattern isn't found, *string* is returned unchanged. | |
| The optional argument *count* is the maximum number of pattern occurrences to be | |
| replaced; *count* must be a non-negative integer. The default value of 0 means | |
| to replace all occurrences. | |
| Here's a simple example of using the :meth:`~re.Pattern.sub` method. It replaces colour | |
| names with the word ``colour``:: | |
| >>> p = re.compile('(blue|white|red)') | |
| >>> p.sub('colour', 'blue socks and red shoes') | |
| 'colour socks and colour shoes' | |
| >>> p.sub('colour', 'blue socks and red shoes', count=1) | |
| 'colour socks and red shoes' | |
| The :meth:`~re.Pattern.subn` method does the same work, but returns a 2-tuple containing the | |
| new string value and the number of replacements that were performed:: | |
| >>> p = re.compile('(blue|white|red)') | |
| >>> p.subn('colour', 'blue socks and red shoes') | |
| ('colour socks and colour shoes', 2) | |
| >>> p.subn('colour', 'no colours at all') | |
| ('no colours at all', 0) | |
| Empty matches are replaced only when they're not adjacent to a previous empty match. | |
| :: | |
| >>> p = re.compile('x*') | |
| >>> p.sub('-', 'abxd') | |
| '-a-b--d-' | |
| If *replacement* is a string, any backslash escapes in it are processed. That | |
| is, ``\n`` is converted to a single newline character, ``\r`` is converted to a | |
| carriage return, and so forth. Unknown escapes such as ``\&`` are left alone. | |
| Backreferences, such as ``\6``, are replaced with the substring matched by the | |
| corresponding group in the RE. This lets you incorporate portions of the | |
| original text in the resulting replacement string. | |
| This example matches the word ``section`` followed by a string enclosed in | |
| ``{``, ``}``, and changes ``section`` to ``subsection``:: | |
| >>> p = re.compile('section{ ( [^}]* ) }', re.VERBOSE) | |
| >>> p.sub(r'subsection{\1}','section{First} section{second}') | |
| 'subsection{First} subsection{second}' | |
| There's also a syntax for referring to named groups as defined by the | |
| ``(?P<name>...)`` syntax. ``\g<name>`` will use the substring matched by the | |
| group named ``name``, and ``\g<number>`` uses the corresponding group number. | |
| ``\g<2>`` is therefore equivalent to ``\2``, but isn't ambiguous in a | |
| replacement string such as ``\g<2>0``. (``\20`` would be interpreted as a | |
| reference to group 20, not a reference to group 2 followed by the literal | |
| character ``'0'``.) The following substitutions are all equivalent, but use all | |
| three variations of the replacement string. :: | |
| >>> p = re.compile('section{ (?P<name> [^}]* ) }', re.VERBOSE) | |
| >>> p.sub(r'subsection{\1}','section{First}') | |
| 'subsection{First}' | |
| >>> p.sub(r'subsection{\g<1>}','section{First}') | |
| 'subsection{First}' | |
| >>> p.sub(r'subsection{\g<name>}','section{First}') | |
| 'subsection{First}' | |
| *replacement* can also be a function, which gives you even more control. If | |
| *replacement* is a function, the function is called for every non-overlapping | |
| occurrence of *pattern*. On each call, the function is passed a | |
| :ref:`match object <match-objects>` argument for the match and can use this | |
| information to compute the desired replacement string and return it. | |
| In the following example, the replacement function translates decimals into | |
| hexadecimal:: | |
| >>> def hexrepl(match): | |
| ... "Return the hex string for a decimal number" | |
| ... value = int(match.group()) | |
| ... return hex(value) | |
| ... | |
| >>> p = re.compile(r'\d+') | |
| >>> p.sub(hexrepl, 'Call 65490 for printing, 49152 for user code.') | |
| 'Call 0xffd2 for printing, 0xc000 for user code.' | |
| When using the module-level :func:`re.sub` function, the pattern is passed as | |
| the first argument. The pattern may be provided as an object or as a string; if | |
| you need to specify regular expression flags, you must either use a | |
| pattern object as the first parameter, or use embedded modifiers in the | |
| pattern string, e.g. ``sub("(?i)b+", "x", "bbbb BBBB")`` returns ``'x x'``. | |
| Common Problems | |
| =============== | |
| Regular expressions are a powerful tool for some applications, but in some ways | |
| their behaviour isn't intuitive and at times they don't behave the way you may | |
| expect them to. This section will point out some of the most common pitfalls. | |
| Use String Methods | |
| ------------------ | |
| Sometimes using the :mod:`re` module is a mistake. If you're matching a fixed | |
| string, or a single character class, and you're not using any :mod:`re` features | |
| such as the :const:`~re.IGNORECASE` flag, then the full power of regular expressions | |
| may not be required. Strings have several methods for performing operations with | |
| fixed strings and they're usually much faster, because the implementation is a | |
| single small C loop that's been optimized for the purpose, instead of the large, | |
| more generalized regular expression engine. | |
| One example might be replacing a single fixed string with another one; for | |
| example, you might replace ``word`` with ``deed``. :func:`re.sub` seems like the | |
| function to use for this, but consider the :meth:`~str.replace` method. Note that | |
| :meth:`!replace` will also replace ``word`` inside words, turning ``swordfish`` | |
| into ``sdeedfish``, but the naive RE ``word`` would have done that, too. (To | |
| avoid performing the substitution on parts of words, the pattern would have to | |
| be ``\bword\b``, in order to require that ``word`` have a word boundary on | |
| either side. This takes the job beyond :meth:`!replace`'s abilities.) | |
| Another common task is deleting every occurrence of a single character from a | |
| string or replacing it with another single character. You might do this with | |
| something like ``re.sub('\n', ' ', S)``, but :meth:`~str.translate` is capable of | |
| doing both tasks and will be faster than any regular expression operation can | |
| be. | |
| In short, before turning to the :mod:`re` module, consider whether your problem | |
| can be solved with a faster and simpler string method. | |
| match() versus search() | |
| ----------------------- | |
| The :func:`~re.match` function only checks if the RE matches at the beginning of the | |
| string while :func:`~re.search` will scan forward through the string for a match. | |
| It's important to keep this distinction in mind. Remember, :func:`!match` will | |
| only report a successful match which will start at 0; if the match wouldn't | |
| start at zero, :func:`!match` will *not* report it. :: | |
| >>> print(re.match('super', 'superstition').span()) | |
| (0, 5) | |
| >>> print(re.match('super', 'insuperable')) | |
| None | |
| On the other hand, :func:`~re.search` will scan forward through the string, | |
| reporting the first match it finds. :: | |
| >>> print(re.search('super', 'superstition').span()) | |
| (0, 5) | |
| >>> print(re.search('super', 'insuperable').span()) | |
| (2, 7) | |
| Sometimes you'll be tempted to keep using :func:`re.match`, and just add ``.*`` | |
| to the front of your RE. Resist this temptation and use :func:`re.search` | |
| instead. The regular expression compiler does some analysis of REs in order to | |
| speed up the process of looking for a match. One such analysis figures out what | |
| the first character of a match must be; for example, a pattern starting with | |
| ``Crow`` must match starting with a ``'C'``. The analysis lets the engine | |
| quickly scan through the string looking for the starting character, only trying | |
| the full match if a ``'C'`` is found. | |
| Adding ``.*`` defeats this optimization, requiring scanning to the end of the | |
| string and then backtracking to find a match for the rest of the RE. Use | |
| :func:`re.search` instead. | |
| Greedy versus Non-Greedy | |
| ------------------------ | |
| When repeating a regular expression, as in ``a*``, the resulting action is to | |
| consume as much of the pattern as possible. This fact often bites you when | |
| you're trying to match a pair of balanced delimiters, such as the angle brackets | |
| surrounding an HTML tag. The naive pattern for matching a single HTML tag | |
| doesn't work because of the greedy nature of ``.*``. :: | |
| >>> s = '<html><head><title>Title</title>' | |
| >>> len(s) | |
| 32 | |
| >>> print(re.match('<.*>', s).span()) | |
| (0, 32) | |
| >>> print(re.match('<.*>', s).group()) | |
| <html><head><title>Title</title> | |
| The RE matches the ``'<'`` in ``'<html>'``, and the ``.*`` consumes the rest of | |
| the string. There's still more left in the RE, though, and the ``>`` can't | |
| match at the end of the string, so the regular expression engine has to | |
| backtrack character by character until it finds a match for the ``>``. The | |
| final match extends from the ``'<'`` in ``'<html>'`` to the ``'>'`` in | |
| ``'</title>'``, which isn't what you want. | |
| In this case, the solution is to use the non-greedy qualifiers ``*?``, ``+?``, | |
| ``??``, or ``{m,n}?``, which match as *little* text as possible. In the above | |
| example, the ``'>'`` is tried immediately after the first ``'<'`` matches, and | |
| when it fails, the engine advances a character at a time, retrying the ``'>'`` | |
| at every step. This produces just the right result:: | |
| >>> print(re.match('<.*?>', s).group()) | |
| <html> | |
| (Note that parsing HTML or XML with regular expressions is painful. | |
| Quick-and-dirty patterns will handle common cases, but HTML and XML have special | |
| cases that will break the obvious regular expression; by the time you've written | |
| a regular expression that handles all of the possible cases, the patterns will | |
| be *very* complicated. Use an HTML or XML parser module for such tasks.) | |
| Using re.VERBOSE | |
| ---------------- | |
| By now you've probably noticed that regular expressions are a very compact | |
| notation, but they're not terribly readable. REs of moderate complexity can | |
| become lengthy collections of backslashes, parentheses, and metacharacters, | |
| making them difficult to read and understand. | |
| For such REs, specifying the :const:`re.VERBOSE` flag when compiling the regular | |
| expression can be helpful, because it allows you to format the regular | |
| expression more clearly. | |
| The ``re.VERBOSE`` flag has several effects. Whitespace in the regular | |
| expression that *isn't* inside a character class is ignored. This means that an | |
| expression such as ``dog | cat`` is equivalent to the less readable ``dog|cat``, | |
| but ``[a b]`` will still match the characters ``'a'``, ``'b'``, or a space. In | |
| addition, you can also put comments inside a RE; comments extend from a ``#`` | |
| character to the next newline. When used with triple-quoted strings, this | |
| enables REs to be formatted more neatly:: | |
| pat = re.compile(r""" | |
| \s* # Skip leading whitespace | |
| (?P<header>[^:]+) # Header name | |
| \s* : # Whitespace, and a colon | |
| (?P<value>.*?) # The header's value -- *? used to | |
| # lose the following trailing whitespace | |
| \s*$ # Trailing whitespace to end-of-line | |
| """, re.VERBOSE) | |
| This is far more readable than:: | |
| pat = re.compile(r"\s*(?P<header>[^:]+)\s*:(?P<value>.*?)\s*$") | |
| Feedback | |
| ======== | |
| Regular expressions are a complicated topic. Did this document help you | |
| understand them? Were there parts that were unclear, or Problems you | |
| encountered that weren't covered here? If so, please send suggestions for | |
| improvements to the author. | |
| The most complete book on regular expressions is almost certainly Jeffrey | |
| Friedl's Mastering Regular Expressions, published by O'Reilly. Unfortunately, | |
| it exclusively concentrates on Perl and Java's flavours of regular expressions, | |
| and doesn't contain any Python material at all, so it won't be useful as a | |
| reference for programming in Python. (The first edition covered Python's | |
| now-removed :mod:`!regex` module, which won't help you much.) Consider checking | |
| it out from your library. |