1 .. _regex-howto: 2 3 **************************** 4 Regular Expression HOWTO 5 **************************** 6 7 :Author: A.M. Kuchling <amk (a] amk.ca> 8 9 .. TODO: 10 Document lookbehind assertions 11 Better way of displaying a RE, a string, and what it matches 12 Mention optional argument to match.groups() 13 Unicode (at least a reference) 14 15 16 .. topic:: Abstract 17 18 This document is an introductory tutorial to using regular expressions in Python 19 with the :mod:`re` module. It provides a gentler introduction than the 20 corresponding section in the Library Reference. 21 22 23 Introduction 24 ============ 25 26 The :mod:`re` module was added in Python 1.5, and provides Perl-style regular 27 expression patterns. Earlier versions of Python came with the :mod:`regex` 28 module, which provided Emacs-style patterns. The :mod:`regex` module was 29 removed completely in Python 2.5. 30 31 Regular expressions (called REs, or regexes, or regex patterns) are essentially 32 a tiny, highly specialized programming language embedded inside Python and made 33 available through the :mod:`re` module. Using this little language, you specify 34 the rules for the set of possible strings that you want to match; this set might 35 contain English sentences, or e-mail addresses, or TeX commands, or anything you 36 like. You can then ask questions such as "Does this string match the pattern?", 37 or "Is there a match for the pattern anywhere in this string?". You can also 38 use REs to modify a string or to split it apart in various ways. 39 40 Regular expression patterns are compiled into a series of bytecodes which are 41 then executed by a matching engine written in C. For advanced use, it may be 42 necessary to pay careful attention to how the engine will execute a given RE, 43 and write the RE in a certain way in order to produce bytecode that runs faster. 44 Optimization isn't covered in this document, because it requires that you have a 45 good understanding of the matching engine's internals. 46 47 The regular expression language is relatively small and restricted, so not all 48 possible string processing tasks can be done using regular expressions. There 49 are also tasks that *can* be done with regular expressions, but the expressions 50 turn out to be very complicated. In these cases, you may be better off writing 51 Python code to do the processing; while Python code will be slower than an 52 elaborate regular expression, it will also probably be more understandable. 53 54 55 Simple Patterns 56 =============== 57 58 We'll start by learning about the simplest possible regular expressions. Since 59 regular expressions are used to operate on strings, we'll begin with the most 60 common task: matching characters. 61 62 For a detailed explanation of the computer science underlying regular 63 expressions (deterministic and non-deterministic finite automata), you can refer 64 to almost any textbook on writing compilers. 65 66 67 Matching Characters 68 ------------------- 69 70 Most letters and characters will simply match themselves. For example, the 71 regular expression ``test`` will match the string ``test`` exactly. (You can 72 enable a case-insensitive mode that would let this RE match ``Test`` or ``TEST`` 73 as well; more about this later.) 74 75 There are exceptions to this rule; some characters are special 76 :dfn:`metacharacters`, and don't match themselves. Instead, they signal that 77 some out-of-the-ordinary thing should be matched, or they affect other portions 78 of the RE by repeating them or changing their meaning. Much of this document is 79 devoted to discussing various metacharacters and what they do. 80 81 Here's a complete list of the metacharacters; their meanings will be discussed 82 in the rest of this HOWTO. 83 84 .. code-block:: none 85 86 . ^ $ * + ? { } [ ] \ | ( ) 87 88 The first metacharacters we'll look at are ``[`` and ``]``. They're used for 89 specifying a character class, which is a set of characters that you wish to 90 match. Characters can be listed individually, or a range of characters can be 91 indicated by giving two characters and separating them by a ``'-'``. For 92 example, ``[abc]`` will match any of the characters ``a``, ``b``, or ``c``; this 93 is the same as ``[a-c]``, which uses a range to express the same set of 94 characters. If you wanted to match only lowercase letters, your RE would be 95 ``[a-z]``. 96 97 Metacharacters are not active inside classes. For example, ``[akm$]`` will 98 match any of the characters ``'a'``, ``'k'``, ``'m'``, or ``'$'``; ``'$'`` is 99 usually a metacharacter, but inside a character class it's stripped of its 100 special nature. 101 102 You can match the characters not listed within the class by :dfn:`complementing` 103 the set. This is indicated by including a ``'^'`` as the first character of the 104 class; ``'^'`` outside a character class will simply match the ``'^'`` 105 character. For example, ``[^5]`` will match any character except ``'5'``. 106 107 Perhaps the most important metacharacter is the backslash, ``\``. As in Python 108 string literals, the backslash can be followed by various characters to signal 109 various special sequences. It's also used to escape all the metacharacters so 110 you can still match them in patterns; for example, if you need to match a ``[`` 111 or ``\``, you can precede them with a backslash to remove their special 112 meaning: ``\[`` or ``\\``. 113 114 Some of the special sequences beginning with ``'\'`` represent predefined sets 115 of characters that are often useful, such as the set of digits, the set of 116 letters, or the set of anything that isn't whitespace. The following predefined 117 special sequences are a subset of those available. The equivalent classes are 118 for byte string patterns. For a complete list of sequences and expanded class 119 definitions for Unicode string patterns, see the last part of 120 :ref:`Regular Expression Syntax <re-syntax>`. 121 122 ``\d`` 123 Matches any decimal digit; this is equivalent to the class ``[0-9]``. 124 125 ``\D`` 126 Matches any non-digit character; this is equivalent to the class ``[^0-9]``. 127 128 ``\s`` 129 Matches any whitespace character; this is equivalent to the class ``[ 130 \t\n\r\f\v]``. 131 132 ``\S`` 133 Matches any non-whitespace character; this is equivalent to the class ``[^ 134 \t\n\r\f\v]``. 135 136 ``\w`` 137 Matches any alphanumeric character; this is equivalent to the class 138 ``[a-zA-Z0-9_]``. 139 140 ``\W`` 141 Matches any non-alphanumeric character; this is equivalent to the class 142 ``[^a-zA-Z0-9_]``. 143 144 These sequences can be included inside a character class. For example, 145 ``[\s,.]`` is a character class that will match any whitespace character, or 146 ``','`` or ``'.'``. 147 148 The final metacharacter in this section is ``.``. It matches anything except a 149 newline character, and there's an alternate mode (``re.DOTALL``) where it will 150 match even a newline. ``'.'`` is often used where you want to match "any 151 character". 152 153 154 Repeating Things 155 ---------------- 156 157 Being able to match varying sets of characters is the first thing regular 158 expressions can do that isn't already possible with the methods available on 159 strings. However, if that was the only additional capability of regexes, they 160 wouldn't be much of an advance. Another capability is that you can specify that 161 portions of the RE must be repeated a certain number of times. 162 163 The first metacharacter for repeating things that we'll look at is ``*``. ``*`` 164 doesn't match the literal character ``*``; instead, it specifies that the 165 previous character can be matched zero or more times, instead of exactly once. 166 167 For example, ``ca*t`` will match ``ct`` (0 ``a`` characters), ``cat`` (1 ``a``), 168 ``caaat`` (3 ``a`` characters), and so forth. The RE engine has various 169 internal limitations stemming from the size of C's ``int`` type that will 170 prevent it from matching over 2 billion ``a`` characters; you probably don't 171 have enough memory to construct a string that large, so you shouldn't run into 172 that limit. 173 174 Repetitions such as ``*`` are :dfn:`greedy`; when repeating a RE, the matching 175 engine will try to repeat it as many times as possible. If later portions of the 176 pattern don't match, the matching engine will then back up and try again with 177 fewer repetitions. 178 179 A step-by-step example will make this more obvious. Let's consider the 180 expression ``a[bcd]*b``. This matches the letter ``'a'``, zero or more letters 181 from the class ``[bcd]``, and finally ends with a ``'b'``. Now imagine matching 182 this RE against the string ``abcbd``. 183 184 +------+-----------+---------------------------------+ 185 | Step | Matched | Explanation | 186 +======+===========+=================================+ 187 | 1 | ``a`` | The ``a`` in the RE matches. | 188 +------+-----------+---------------------------------+ 189 | 2 | ``abcbd`` | The engine matches ``[bcd]*``, | 190 | | | going as far as it can, which | 191 | | | is to the end of the string. | 192 +------+-----------+---------------------------------+ 193 | 3 | *Failure* | The engine tries to match | 194 | | | ``b``, but the current position | 195 | | | is at the end of the string, so | 196 | | | it fails. | 197 +------+-----------+---------------------------------+ 198 | 4 | ``abcb`` | Back up, so that ``[bcd]*`` | 199 | | | matches one less character. | 200 +------+-----------+---------------------------------+ 201 | 5 | *Failure* | Try ``b`` again, but the | 202 | | | current position is at the last | 203 | | | character, which is a ``'d'``. | 204 +------+-----------+---------------------------------+ 205 | 6 | ``abc`` | Back up again, so that | 206 | | | ``[bcd]*`` is only matching | 207 | | | ``bc``. | 208 +------+-----------+---------------------------------+ 209 | 6 | ``abcb`` | Try ``b`` again. This time | 210 | | | the character at the | 211 | | | current position is ``'b'``, so | 212 | | | it succeeds. | 213 +------+-----------+---------------------------------+ 214 215 The end of the RE has now been reached, and it has matched ``abcb``. This 216 demonstrates how the matching engine goes as far as it can at first, and if no 217 match is found it will then progressively back up and retry the rest of the RE 218 again and again. It will back up until it has tried zero matches for 219 ``[bcd]*``, and if that subsequently fails, the engine will conclude that the 220 string doesn't match the RE at all. 221 222 Another repeating metacharacter is ``+``, which matches one or more times. Pay 223 careful attention to the difference between ``*`` and ``+``; ``*`` matches 224 *zero* or more times, so whatever's being repeated may not be present at all, 225 while ``+`` requires at least *one* occurrence. To use a similar example, 226 ``ca+t`` will match ``cat`` (1 ``a``), ``caaat`` (3 ``a``'s), but won't match 227 ``ct``. 228 229 There are two more repeating qualifiers. The question mark character, ``?``, 230 matches either once or zero times; you can think of it as marking something as 231 being optional. For example, ``home-?brew`` matches either ``homebrew`` or 232 ``home-brew``. 233 234 The most complicated repeated qualifier is ``{m,n}``, where *m* and *n* are 235 decimal integers. This qualifier means there must be at least *m* repetitions, 236 and at most *n*. For example, ``a/{1,3}b`` will match ``a/b``, ``a//b``, and 237 ``a///b``. It won't match ``ab``, which has no slashes, or ``a////b``, which 238 has four. 239 240 You can omit either *m* or *n*; in that case, a reasonable value is assumed for 241 the missing value. Omitting *m* is interpreted as a lower limit of 0, while 242 omitting *n* results in an upper bound of infinity --- actually, the upper bound 243 is the 2-billion limit mentioned earlier, but that might as well be infinity. 244 245 Readers of a reductionist bent may notice that the three other qualifiers can 246 all be expressed using this notation. ``{0,}`` is the same as ``*``, ``{1,}`` 247 is equivalent to ``+``, and ``{0,1}`` is the same as ``?``. It's better to use 248 ``*``, ``+``, or ``?`` when you can, simply because they're shorter and easier 249 to read. 250 251 252 Using Regular Expressions 253 ========================= 254 255 Now that we've looked at some simple regular expressions, how do we actually use 256 them in Python? The :mod:`re` module provides an interface to the regular 257 expression engine, allowing you to compile REs into objects and then perform 258 matches with them. 259 260 261 Compiling Regular Expressions 262 ----------------------------- 263 264 Regular expressions are compiled into pattern objects, which have 265 methods for various operations such as searching for pattern matches or 266 performing string substitutions. :: 267 268 >>> import re 269 >>> p = re.compile('ab*') 270 >>> p #doctest: +ELLIPSIS 271 <_sre.SRE_Pattern object at 0x...> 272 273 :func:`re.compile` also accepts an optional *flags* argument, used to enable 274 various special features and syntax variations. We'll go over the available 275 settings later, but for now a single example will do:: 276 277 >>> p = re.compile('ab*', re.IGNORECASE) 278 279 The RE is passed to :func:`re.compile` as a string. REs are handled as strings 280 because regular expressions aren't part of the core Python language, and no 281 special syntax was created for expressing them. (There are applications that 282 don't need REs at all, so there's no need to bloat the language specification by 283 including them.) Instead, the :mod:`re` module is simply a C extension module 284 included with Python, just like the :mod:`socket` or :mod:`zlib` modules. 285 286 Putting REs in strings keeps the Python language simpler, but has one 287 disadvantage which is the topic of the next section. 288 289 290 The Backslash Plague 291 -------------------- 292 293 As stated earlier, regular expressions use the backslash character (``'\'``) to 294 indicate special forms or to allow special characters to be used without 295 invoking their special meaning. This conflicts with Python's usage of the same 296 character for the same purpose in string literals. 297 298 Let's say you want to write a RE that matches the string ``\section``, which 299 might be found in a LaTeX file. To figure out what to write in the program 300 code, start with the desired string to be matched. Next, you must escape any 301 backslashes and other metacharacters by preceding them with a backslash, 302 resulting in the string ``\\section``. The resulting string that must be passed 303 to :func:`re.compile` must be ``\\section``. However, to express this as a 304 Python string literal, both backslashes must be escaped *again*. 305 306 +-------------------+------------------------------------------+ 307 | Characters | Stage | 308 +===================+==========================================+ 309 | ``\section`` | Text string to be matched | 310 +-------------------+------------------------------------------+ 311 | ``\\section`` | Escaped backslash for :func:`re.compile` | 312 +-------------------+------------------------------------------+ 313 | ``"\\\\section"`` | Escaped backslashes for a string literal | 314 +-------------------+------------------------------------------+ 315 316 In short, to match a literal backslash, one has to write ``'\\\\'`` as the RE 317 string, because the regular expression must be ``\\``, and each backslash must 318 be expressed as ``\\`` inside a regular Python string literal. In REs that 319 feature backslashes repeatedly, this leads to lots of repeated backslashes and 320 makes the resulting strings difficult to understand. 321 322 The solution is to use Python's raw string notation for regular expressions; 323 backslashes are not handled in any special way in a string literal prefixed with 324 ``'r'``, so ``r"\n"`` is a two-character string containing ``'\'`` and ``'n'``, 325 while ``"\n"`` is a one-character string containing a newline. Regular 326 expressions will often be written in Python code using this raw string notation. 327 328 +-------------------+------------------+ 329 | Regular String | Raw string | 330 +===================+==================+ 331 | ``"ab*"`` | ``r"ab*"`` | 332 +-------------------+------------------+ 333 | ``"\\\\section"`` | ``r"\\section"`` | 334 +-------------------+------------------+ 335 | ``"\\w+\\s+\\1"`` | ``r"\w+\s+\1"`` | 336 +-------------------+------------------+ 337 338 339 Performing Matches 340 ------------------ 341 342 Once you have an object representing a compiled regular expression, what do you 343 do with it? Pattern objects have several methods and attributes. 344 Only the most significant ones will be covered here; consult the :mod:`re` docs 345 for a complete listing. 346 347 +------------------+-----------------------------------------------+ 348 | Method/Attribute | Purpose | 349 +==================+===============================================+ 350 | ``match()`` | Determine if the RE matches at the beginning | 351 | | of the string. | 352 +------------------+-----------------------------------------------+ 353 | ``search()`` | Scan through a string, looking for any | 354 | | location where this RE matches. | 355 +------------------+-----------------------------------------------+ 356 | ``findall()`` | Find all substrings where the RE matches, and | 357 | | returns them as a list. | 358 +------------------+-----------------------------------------------+ 359 | ``finditer()`` | Find all substrings where the RE matches, and | 360 | | returns them as an :term:`iterator`. | 361 +------------------+-----------------------------------------------+ 362 363 :meth:`match` and :meth:`search` return ``None`` if no match can be found. If 364 they're successful, a :ref:`match object <match-objects>` instance is returned, 365 containing information about the match: where it starts and ends, the substring 366 it matched, and more. 367 368 You can learn about this by interactively experimenting with the :mod:`re` 369 module. If you have Tkinter available, you may also want to look at 370 :source:`Tools/scripts/redemo.py`, a demonstration program included with the 371 Python distribution. It allows you to enter REs and strings, and displays 372 whether the RE matches or fails. :file:`redemo.py` can be quite useful when 373 trying to debug a complicated RE. Phil Schwartz's `Kodos 374 <http://kodos.sourceforge.net/>`_ is also an interactive tool for developing and 375 testing RE patterns. 376 377 This HOWTO uses the standard Python interpreter for its examples. First, run the 378 Python interpreter, import the :mod:`re` module, and compile a RE:: 379 380 Python 2.2.2 (#1, Feb 10 2003, 12:57:01) 381 >>> import re 382 >>> p = re.compile('[a-z]+') 383 >>> p #doctest: +ELLIPSIS 384 <_sre.SRE_Pattern object at 0x...> 385 386 Now, you can try matching various strings against the RE ``[a-z]+``. An empty 387 string shouldn't match at all, since ``+`` means 'one or more repetitions'. 388 :meth:`match` should return ``None`` in this case, which will cause the 389 interpreter to print no output. You can explicitly print the result of 390 :meth:`match` to make this clear. :: 391 392 >>> p.match("") 393 >>> print p.match("") 394 None 395 396 Now, let's try it on a string that it should match, such as ``tempo``. In this 397 case, :meth:`match` will return a :ref:`match object <match-objects>`, so you 398 should store the result in a variable for later use. :: 399 400 >>> m = p.match('tempo') 401 >>> m #doctest: +ELLIPSIS 402 <_sre.SRE_Match object at 0x...> 403 404 Now you can query the :ref:`match object <match-objects>` for information 405 about the matching string. :ref:`match object <match-objects>` instances 406 also have several methods and attributes; the most important ones are: 407 408 +------------------+--------------------------------------------+ 409 | Method/Attribute | Purpose | 410 +==================+============================================+ 411 | ``group()`` | Return the string matched by the RE | 412 +------------------+--------------------------------------------+ 413 | ``start()`` | Return the starting position of the match | 414 +------------------+--------------------------------------------+ 415 | ``end()`` | Return the ending position of the match | 416 +------------------+--------------------------------------------+ 417 | ``span()`` | Return a tuple containing the (start, end) | 418 | | positions of the match | 419 +------------------+--------------------------------------------+ 420 421 Trying these methods will soon clarify their meaning:: 422 423 >>> m.group() 424 'tempo' 425 >>> m.start(), m.end() 426 (0, 5) 427 >>> m.span() 428 (0, 5) 429 430 :meth:`group` returns the substring that was matched by the RE. :meth:`start` 431 and :meth:`end` return the starting and ending index of the match. :meth:`span` 432 returns both start and end indexes in a single tuple. Since the :meth:`match` 433 method only checks if the RE matches at the start of a string, :meth:`start` 434 will always be zero. However, the :meth:`search` method of patterns 435 scans through the string, so the match may not start at zero in that 436 case. :: 437 438 >>> print p.match('::: message') 439 None 440 >>> m = p.search('::: message'); print m #doctest: +ELLIPSIS 441 <_sre.SRE_Match object at 0x...> 442 >>> m.group() 443 'message' 444 >>> m.span() 445 (4, 11) 446 447 In actual programs, the most common style is to store the 448 :ref:`match object <match-objects>` in a variable, and then check if it was 449 ``None``. This usually looks like:: 450 451 p = re.compile( ... ) 452 m = p.match( 'string goes here' ) 453 if m: 454 print 'Match found: ', m.group() 455 else: 456 print 'No match' 457 458 Two pattern methods return all of the matches for a pattern. 459 :meth:`findall` returns a list of matching strings:: 460 461 >>> p = re.compile('\d+') 462 >>> p.findall('12 drummers drumming, 11 pipers piping, 10 lords a-leaping') 463 ['12', '11', '10'] 464 465 :meth:`findall` has to create the entire list before it can be returned as the 466 result. The :meth:`finditer` method returns a sequence of 467 :ref:`match object <match-objects>` instances as an :term:`iterator`. [#]_ :: 468 469 >>> iterator = p.finditer('12 drummers drumming, 11 ... 10 ...') 470 >>> iterator #doctest: +ELLIPSIS 471 <callable-iterator object at 0x...> 472 >>> for match in iterator: 473 ... print match.span() 474 ... 475 (0, 2) 476 (22, 24) 477 (29, 31) 478 479 480 Module-Level Functions 481 ---------------------- 482 483 You don't have to create a pattern object and call its methods; the 484 :mod:`re` module also provides top-level functions called :func:`match`, 485 :func:`search`, :func:`findall`, :func:`sub`, and so forth. These functions 486 take the same arguments as the corresponding pattern method, with 487 the RE string added as the first argument, and still return either ``None`` or a 488 :ref:`match object <match-objects>` instance. :: 489 490 >>> print re.match(r'From\s+', 'Fromage amk') 491 None 492 >>> re.match(r'From\s+', 'From amk Thu May 14 19:12:10 1998') #doctest: +ELLIPSIS 493 <_sre.SRE_Match object at 0x...> 494 495 Under the hood, these functions simply create a pattern object for you 496 and call the appropriate method on it. They also store the compiled object in a 497 cache, so future calls using the same RE are faster. 498 499 Should you use these module-level functions, or should you get the 500 pattern and call its methods yourself? That choice depends on how 501 frequently the RE will be used, and on your personal coding style. If the RE is 502 being used at only one point in the code, then the module functions are probably 503 more convenient. If a program contains a lot of regular expressions, or re-uses 504 the same ones in several locations, then it might be worthwhile to collect all 505 the definitions in one place, in a section of code that compiles all the REs 506 ahead of time. To take an example from the standard library, here's an extract 507 from the deprecated :mod:`xmllib` module:: 508 509 ref = re.compile( ... ) 510 entityref = re.compile( ... ) 511 charref = re.compile( ... ) 512 starttagopen = re.compile( ... ) 513 514 I generally prefer to work with the compiled object, even for one-time uses, but 515 few people will be as much of a purist about this as I am. 516 517 518 Compilation Flags 519 ----------------- 520 521 Compilation flags let you modify some aspects of how regular expressions work. 522 Flags are available in the :mod:`re` module under two names, a long name such as 523 :const:`IGNORECASE` and a short, one-letter form such as :const:`I`. (If you're 524 familiar with Perl's pattern modifiers, the one-letter forms use the same 525 letters; the short form of :const:`re.VERBOSE` is :const:`re.X`, for example.) 526 Multiple flags can be specified by bitwise OR-ing them; ``re.I | re.M`` sets 527 both the :const:`I` and :const:`M` flags, for example. 528 529 Here's a table of the available flags, followed by a more detailed explanation 530 of each one. 531 532 +---------------------------------+--------------------------------------------+ 533 | Flag | Meaning | 534 +=================================+============================================+ 535 | :const:`DOTALL`, :const:`S` | Make ``.`` match any character, including | 536 | | newlines | 537 +---------------------------------+--------------------------------------------+ 538 | :const:`IGNORECASE`, :const:`I` | Do case-insensitive matches | 539 +---------------------------------+--------------------------------------------+ 540 | :const:`LOCALE`, :const:`L` | Do a locale-aware match | 541 +---------------------------------+--------------------------------------------+ 542 | :const:`MULTILINE`, :const:`M` | Multi-line matching, affecting ``^`` and | 543 | | ``$`` | 544 +---------------------------------+--------------------------------------------+ 545 | :const:`VERBOSE`, :const:`X` | Enable verbose REs, which can be organized | 546 | | more cleanly and understandably. | 547 +---------------------------------+--------------------------------------------+ 548 | :const:`UNICODE`, :const:`U` | Makes several escapes like ``\w``, ``\b``, | 549 | | ``\s`` and ``\d`` dependent on the Unicode | 550 | | character database. | 551 +---------------------------------+--------------------------------------------+ 552 553 554 .. data:: I 555 IGNORECASE 556 :noindex: 557 558 Perform case-insensitive matching; character class and literal strings will 559 match letters by ignoring case. For example, ``[A-Z]`` will match lowercase 560 letters, too, and ``Spam`` will match ``Spam``, ``spam``, or ``spAM``. This 561 lowercasing doesn't take the current locale into account; it will if you also 562 set the :const:`LOCALE` flag. 563 564 565 .. data:: L 566 LOCALE 567 :noindex: 568 569 Make ``\w``, ``\W``, ``\b``, and ``\B``, dependent on the current locale. 570 571 Locales are a feature of the C library intended to help in writing programs that 572 take account of language differences. For example, if you're processing French 573 text, you'd want to be able to write ``\w+`` to match words, but ``\w`` only 574 matches the character class ``[A-Za-z]``; it won't match ``''`` or ``''``. If 575 your system is configured properly and a French locale is selected, certain C 576 functions will tell the program that ``''`` should also be considered a letter. 577 Setting the :const:`LOCALE` flag when compiling a regular expression will cause 578 the resulting compiled object to use these C functions for ``\w``; this is 579 slower, but also enables ``\w+`` to match French words as you'd expect. 580 581 582 .. data:: M 583 MULTILINE 584 :noindex: 585 586 (``^`` and ``$`` haven't been explained yet; they'll be introduced in section 587 :ref:`more-metacharacters`.) 588 589 Usually ``^`` matches only at the beginning of the string, and ``$`` matches 590 only at the end of the string and immediately before the newline (if any) at the 591 end of the string. When this flag is specified, ``^`` matches at the beginning 592 of the string and at the beginning of each line within the string, immediately 593 following each newline. Similarly, the ``$`` metacharacter matches either at 594 the end of the string and at the end of each line (immediately preceding each 595 newline). 596 597 598 .. data:: S 599 DOTALL 600 :noindex: 601 602 Makes the ``'.'`` special character match any character at all, including a 603 newline; without this flag, ``'.'`` will match anything *except* a newline. 604 605 606 .. data:: U 607 UNICODE 608 :noindex: 609 610 Make ``\w``, ``\W``, ``\b``, ``\B``, ``\d``, ``\D``, ``\s`` and ``\S`` 611 dependent on the Unicode character properties database. 612 613 614 .. data:: X 615 VERBOSE 616 :noindex: 617 618 This flag allows you to write regular expressions that are more readable by 619 granting you more flexibility in how you can format them. When this flag has 620 been specified, whitespace within the RE string is ignored, except when the 621 whitespace is in a character class or preceded by an unescaped backslash; this 622 lets you organize and indent the RE more clearly. This flag also lets you put 623 comments within a RE that will be ignored by the engine; comments are marked by 624 a ``'#'`` that's neither in a character class or preceded by an unescaped 625 backslash. 626 627 For example, here's a RE that uses :const:`re.VERBOSE`; see how much easier it 628 is to read? :: 629 630 charref = re.compile(r""" 631 &[#] # Start of a numeric entity reference 632 ( 633 0[0-7]+ # Octal form 634 | [0-9]+ # Decimal form 635 | x[0-9a-fA-F]+ # Hexadecimal form 636 ) 637 ; # Trailing semicolon 638 """, re.VERBOSE) 639 640 Without the verbose setting, the RE would look like this:: 641 642 charref = re.compile("&#(0[0-7]+" 643 "|[0-9]+" 644 "|x[0-9a-fA-F]+);") 645 646 In the above example, Python's automatic concatenation of string literals has 647 been used to break up the RE into smaller pieces, but it's still more difficult 648 to understand than the version using :const:`re.VERBOSE`. 649 650 651 More Pattern Power 652 ================== 653 654 So far we've only covered a part of the features of regular expressions. In 655 this section, we'll cover some new metacharacters, and how to use groups to 656 retrieve portions of the text that was matched. 657 658 659 .. _more-metacharacters: 660 661 More Metacharacters 662 ------------------- 663 664 There are some metacharacters that we haven't covered yet. Most of them will be 665 covered in this section. 666 667 Some of the remaining metacharacters to be discussed are :dfn:`zero-width 668 assertions`. They don't cause the engine to advance through the string; 669 instead, they consume no characters at all, and simply succeed or fail. For 670 example, ``\b`` is an assertion that the current position is located at a word 671 boundary; the position isn't changed by the ``\b`` at all. This means that 672 zero-width assertions should never be repeated, because if they match once at a 673 given location, they can obviously be matched an infinite number of times. 674 675 ``|`` 676 Alternation, or the "or" operator. If A and B are regular expressions, 677 ``A|B`` will match any string that matches either ``A`` or ``B``. ``|`` has very 678 low precedence in order to make it work reasonably when you're alternating 679 multi-character strings. ``Crow|Servo`` will match either ``Crow`` or ``Servo``, 680 not ``Cro``, a ``'w'`` or an ``'S'``, and ``ervo``. 681 682 To match a literal ``'|'``, use ``\|``, or enclose it inside a character class, 683 as in ``[|]``. 684 685 ``^`` 686 Matches at the beginning of lines. Unless the :const:`MULTILINE` flag has been 687 set, this will only match at the beginning of the string. In :const:`MULTILINE` 688 mode, this also matches immediately after each newline within the string. 689 690 For example, if you wish to match the word ``From`` only at the beginning of a 691 line, the RE to use is ``^From``. :: 692 693 >>> print re.search('^From', 'From Here to Eternity') #doctest: +ELLIPSIS 694 <_sre.SRE_Match object at 0x...> 695 >>> print re.search('^From', 'Reciting From Memory') 696 None 697 698 .. To match a literal \character{\^}, use \regexp{\e\^} or enclose it 699 .. inside a character class, as in \regexp{[{\e}\^]}. 700 701 ``$`` 702 Matches at the end of a line, which is defined as either the end of the string, 703 or any location followed by a newline character. :: 704 705 >>> print re.search('}$', '{block}') #doctest: +ELLIPSIS 706 <_sre.SRE_Match object at 0x...> 707 >>> print re.search('}$', '{block} ') 708 None 709 >>> print re.search('}$', '{block}\n') #doctest: +ELLIPSIS 710 <_sre.SRE_Match object at 0x...> 711 712 To match a literal ``'$'``, use ``\$`` or enclose it inside a character class, 713 as in ``[$]``. 714 715 ``\A`` 716 Matches only at the start of the string. When not in :const:`MULTILINE` mode, 717 ``\A`` and ``^`` are effectively the same. In :const:`MULTILINE` mode, they're 718 different: ``\A`` still matches only at the beginning of the string, but ``^`` 719 may match at any location inside the string that follows a newline character. 720 721 ``\Z`` 722 Matches only at the end of the string. 723 724 ``\b`` 725 Word boundary. This is a zero-width assertion that matches only at the 726 beginning or end of a word. A word is defined as a sequence of alphanumeric 727 characters, so the end of a word is indicated by whitespace or a 728 non-alphanumeric character. 729 730 The following example matches ``class`` only when it's a complete word; it won't 731 match when it's contained inside another word. :: 732 733 >>> p = re.compile(r'\bclass\b') 734 >>> print p.search('no class at all') #doctest: +ELLIPSIS 735 <_sre.SRE_Match object at 0x...> 736 >>> print p.search('the declassified algorithm') 737 None 738 >>> print p.search('one subclass is') 739 None 740 741 There are two subtleties you should remember when using this special sequence. 742 First, this is the worst collision between Python's string literals and regular 743 expression sequences. In Python's string literals, ``\b`` is the backspace 744 character, ASCII value 8. If you're not using raw strings, then Python will 745 convert the ``\b`` to a backspace, and your RE won't match as you expect it to. 746 The following example looks the same as our previous RE, but omits the ``'r'`` 747 in front of the RE string. :: 748 749 >>> p = re.compile('\bclass\b') 750 >>> print p.search('no class at all') 751 None 752 >>> print p.search('\b' + 'class' + '\b') #doctest: +ELLIPSIS 753 <_sre.SRE_Match object at 0x...> 754 755 Second, inside a character class, where there's no use for this assertion, 756 ``\b`` represents the backspace character, for compatibility with Python's 757 string literals. 758 759 ``\B`` 760 Another zero-width assertion, this is the opposite of ``\b``, only matching when 761 the current position is not at a word boundary. 762 763 764 Grouping 765 -------- 766 767 Frequently you need to obtain more information than just whether the RE matched 768 or not. Regular expressions are often used to dissect strings by writing a RE 769 divided into several subgroups which match different components of interest. 770 For example, an RFC-822 header line is divided into a header name and a value, 771 separated by a ``':'``, like this:: 772 773 From: author (a] example.com 774 User-Agent: Thunderbird 1.5.0.9 (X11/20061227) 775 MIME-Version: 1.0 776 To: editor (a] example.com 777 778 This can be handled by writing a regular expression which matches an entire 779 header line, and has one group which matches the header name, and another group 780 which matches the header's value. 781 782 Groups are marked by the ``'('``, ``')'`` metacharacters. ``'('`` and ``')'`` 783 have much the same meaning as they do in mathematical expressions; they group 784 together the expressions contained inside them, and you can repeat the contents 785 of a group with a repeating qualifier, such as ``*``, ``+``, ``?``, or 786 ``{m,n}``. For example, ``(ab)*`` will match zero or more repetitions of 787 ``ab``. :: 788 789 >>> p = re.compile('(ab)*') 790 >>> print p.match('ababababab').span() 791 (0, 10) 792 793 Groups indicated with ``'('``, ``')'`` also capture the starting and ending 794 index of the text that they match; this can be retrieved by passing an argument 795 to :meth:`group`, :meth:`start`, :meth:`end`, and :meth:`span`. Groups are 796 numbered starting with 0. Group 0 is always present; it's the whole RE, so 797 :ref:`match object <match-objects>` methods all have group 0 as their default 798 argument. Later we'll see how to express groups that don't capture the span 799 of text that they match. :: 800 801 >>> p = re.compile('(a)b') 802 >>> m = p.match('ab') 803 >>> m.group() 804 'ab' 805 >>> m.group(0) 806 'ab' 807 808 Subgroups are numbered from left to right, from 1 upward. Groups can be nested; 809 to determine the number, just count the opening parenthesis characters, going 810 from left to right. :: 811 812 >>> p = re.compile('(a(b)c)d') 813 >>> m = p.match('abcd') 814 >>> m.group(0) 815 'abcd' 816 >>> m.group(1) 817 'abc' 818 >>> m.group(2) 819 'b' 820 821 :meth:`group` can be passed multiple group numbers at a time, in which case it 822 will return a tuple containing the corresponding values for those groups. :: 823 824 >>> m.group(2,1,2) 825 ('b', 'abc', 'b') 826 827 The :meth:`groups` method returns a tuple containing the strings for all the 828 subgroups, from 1 up to however many there are. :: 829 830 >>> m.groups() 831 ('abc', 'b') 832 833 Backreferences in a pattern allow you to specify that the contents of an earlier 834 capturing group must also be found at the current location in the string. For 835 example, ``\1`` will succeed if the exact contents of group 1 can be found at 836 the current position, and fails otherwise. Remember that Python's string 837 literals also use a backslash followed by numbers to allow including arbitrary 838 characters in a string, so be sure to use a raw string when incorporating 839 backreferences in a RE. 840 841 For example, the following RE detects doubled words in a string. :: 842 843 >>> p = re.compile(r'\b(\w+)\s+\1\b') 844 >>> p.search('Paris in the the spring').group() 845 'the the' 846 847 Backreferences like this aren't often useful for just searching through a string 848 --- there are few text formats which repeat data in this way --- but you'll soon 849 find out that they're *very* useful when performing string substitutions. 850 851 852 Non-capturing and Named Groups 853 ------------------------------ 854 855 Elaborate REs may use many groups, both to capture substrings of interest, and 856 to group and structure the RE itself. In complex REs, it becomes difficult to 857 keep track of the group numbers. There are two features which help with this 858 problem. Both of them use a common syntax for regular expression extensions, so 859 we'll look at that first. 860 861 Perl 5 added several additional features to standard regular expressions, and 862 the Python :mod:`re` module supports most of them. It would have been 863 difficult to choose new single-keystroke metacharacters or new special sequences 864 beginning with ``\`` to represent the new features without making Perl's regular 865 expressions confusingly different from standard REs. If you chose ``&`` as a 866 new metacharacter, for example, old expressions would be assuming that ``&`` was 867 a regular character and wouldn't have escaped it by writing ``\&`` or ``[&]``. 868 869 The solution chosen by the Perl developers was to use ``(?...)`` as the 870 extension syntax. ``?`` immediately after a parenthesis was a syntax error 871 because the ``?`` would have nothing to repeat, so this didn't introduce any 872 compatibility problems. The characters immediately after the ``?`` indicate 873 what extension is being used, so ``(?=foo)`` is one thing (a positive lookahead 874 assertion) and ``(?:foo)`` is something else (a non-capturing group containing 875 the subexpression ``foo``). 876 877 Python adds an extension syntax to Perl's extension syntax. If the first 878 character after the question mark is a ``P``, you know that it's an extension 879 that's specific to Python. Currently there are two such extensions: 880 ``(?P<name>...)`` defines a named group, and ``(?P=name)`` is a backreference to 881 a named group. If future versions of Perl 5 add similar features using a 882 different syntax, the :mod:`re` module will be changed to support the new 883 syntax, while preserving the Python-specific syntax for compatibility's sake. 884 885 Now that we've looked at the general extension syntax, we can return to the 886 features that simplify working with groups in complex REs. Since groups are 887 numbered from left to right and a complex expression may use many groups, it can 888 become difficult to keep track of the correct numbering. Modifying such a 889 complex RE is annoying, too: insert a new group near the beginning and you 890 change the numbers of everything that follows it. 891 892 Sometimes you'll want to use a group to collect a part of a regular expression, 893 but aren't interested in retrieving the group's contents. You can make this fact 894 explicit by using a non-capturing group: ``(?:...)``, where you can replace the 895 ``...`` with any other regular expression. :: 896 897 >>> m = re.match("([abc])+", "abc") 898 >>> m.groups() 899 ('c',) 900 >>> m = re.match("(?:[abc])+", "abc") 901 >>> m.groups() 902 () 903 904 Except for the fact that you can't retrieve the contents of what the group 905 matched, a non-capturing group behaves exactly the same as a capturing group; 906 you can put anything inside it, repeat it with a repetition metacharacter such 907 as ``*``, and nest it within other groups (capturing or non-capturing). 908 ``(?:...)`` is particularly useful when modifying an existing pattern, since you 909 can add new groups without changing how all the other groups are numbered. It 910 should be mentioned that there's no performance difference in searching between 911 capturing and non-capturing groups; neither form is any faster than the other. 912 913 A more significant feature is named groups: instead of referring to them by 914 numbers, groups can be referenced by a name. 915 916 The syntax for a named group is one of the Python-specific extensions: 917 ``(?P<name>...)``. *name* is, obviously, the name of the group. Named groups 918 also behave exactly like capturing groups, and additionally associate a name 919 with a group. The :ref:`match object <match-objects>` methods that deal with 920 capturing groups all accept either integers that refer to the group by number 921 or strings that contain the desired group's name. Named groups are still 922 given numbers, so you can retrieve information about a group in two ways:: 923 924 >>> p = re.compile(r'(?P<word>\b\w+\b)') 925 >>> m = p.search( '(((( Lots of punctuation )))' ) 926 >>> m.group('word') 927 'Lots' 928 >>> m.group(1) 929 'Lots' 930 931 Named groups are handy because they let you use easily-remembered names, instead 932 of having to remember numbers. Here's an example RE from the :mod:`imaplib` 933 module:: 934 935 InternalDate = re.compile(r'INTERNALDATE "' 936 r'(?P<day>[ 123][0-9])-(?P<mon>[A-Z][a-z][a-z])-' 937 r'(?P<year>[0-9][0-9][0-9][0-9])' 938 r' (?P<hour>[0-9][0-9]):(?P<min>[0-9][0-9]):(?P<sec>[0-9][0-9])' 939 r' (?P<zonen>[-+])(?P<zoneh>[0-9][0-9])(?P<zonem>[0-9][0-9])' 940 r'"') 941 942 It's obviously much easier to retrieve ``m.group('zonem')``, instead of having 943 to remember to retrieve group 9. 944 945 The syntax for backreferences in an expression such as ``(...)\1`` refers to the 946 number of the group. There's naturally a variant that uses the group name 947 instead of the number. This is another Python extension: ``(?P=name)`` indicates 948 that the contents of the group called *name* should again be matched at the 949 current point. The regular expression for finding doubled words, 950 ``\b(\w+)\s+\1\b`` can also be written as ``\b(?P<word>\w+)\s+(?P=word)\b``:: 951 952 >>> p = re.compile(r'\b(?P<word>\w+)\s+(?P=word)\b') 953 >>> p.search('Paris in the the spring').group() 954 'the the' 955 956 957 Lookahead Assertions 958 -------------------- 959 960 Another zero-width assertion is the lookahead assertion. Lookahead assertions 961 are available in both positive and negative form, and look like this: 962 963 ``(?=...)`` 964 Positive lookahead assertion. This succeeds if the contained regular 965 expression, represented here by ``...``, successfully matches at the current 966 location, and fails otherwise. But, once the contained expression has been 967 tried, the matching engine doesn't advance at all; the rest of the pattern is 968 tried right where the assertion started. 969 970 ``(?!...)`` 971 Negative lookahead assertion. This is the opposite of the positive assertion; 972 it succeeds if the contained expression *doesn't* match at the current position 973 in the string. 974 975 To make this concrete, let's look at a case where a lookahead is useful. 976 Consider a simple pattern to match a filename and split it apart into a base 977 name and an extension, separated by a ``.``. For example, in ``news.rc``, 978 ``news`` is the base name, and ``rc`` is the filename's extension. 979 980 The pattern to match this is quite simple: 981 982 ``.*[.].*$`` 983 984 Notice that the ``.`` needs to be treated specially because it's a 985 metacharacter; I've put it inside a character class. Also notice the trailing 986 ``$``; this is added to ensure that all the rest of the string must be included 987 in the extension. This regular expression matches ``foo.bar`` and 988 ``autoexec.bat`` and ``sendmail.cf`` and ``printers.conf``. 989 990 Now, consider complicating the problem a bit; what if you want to match 991 filenames where the extension is not ``bat``? Some incorrect attempts: 992 993 ``.*[.][^b].*$`` The first attempt above tries to exclude ``bat`` by requiring 994 that the first character of the extension is not a ``b``. This is wrong, 995 because the pattern also doesn't match ``foo.bar``. 996 997 ``.*[.]([^b]..|.[^a].|..[^t])$`` 998 999 The expression gets messier when you try to patch up the first solution by 1000 requiring one of the following cases to match: the first character of the 1001 extension isn't ``b``; the second character isn't ``a``; or the third character 1002 isn't ``t``. This accepts ``foo.bar`` and rejects ``autoexec.bat``, but it 1003 requires a three-letter extension and won't accept a filename with a two-letter 1004 extension such as ``sendmail.cf``. We'll complicate the pattern again in an 1005 effort to fix it. 1006 1007 ``.*[.]([^b].?.?|.[^a]?.?|..?[^t]?)$`` 1008 1009 In the third attempt, the second and third letters are all made optional in 1010 order to allow matching extensions shorter than three characters, such as 1011 ``sendmail.cf``. 1012 1013 The pattern's getting really complicated now, which makes it hard to read and 1014 understand. Worse, if the problem changes and you want to exclude both ``bat`` 1015 and ``exe`` as extensions, the pattern would get even more complicated and 1016 confusing. 1017 1018 A negative lookahead cuts through all this confusion: 1019 1020 ``.*[.](?!bat$)[^.]*$`` The negative lookahead means: if the expression ``bat`` 1021 doesn't match at this point, try the rest of the pattern; if ``bat$`` does 1022 match, the whole pattern will fail. The trailing ``$`` is required to ensure 1023 that something like ``sample.batch``, where the extension only starts with 1024 ``bat``, will be allowed. The ``[^.]*`` makes sure that the pattern works 1025 when there are multiple dots in the filename. 1026 1027 Excluding another filename extension is now easy; simply add it as an 1028 alternative inside the assertion. The following pattern excludes filenames that 1029 end in either ``bat`` or ``exe``: 1030 1031 ``.*[.](?!bat$|exe$)[^.]*$`` 1032 1033 1034 Modifying Strings 1035 ================= 1036 1037 Up to this point, we've simply performed searches against a static string. 1038 Regular expressions are also commonly used to modify strings in various ways, 1039 using the following pattern methods: 1040 1041 +------------------+-----------------------------------------------+ 1042 | Method/Attribute | Purpose | 1043 +==================+===============================================+ 1044 | ``split()`` | Split the string into a list, splitting it | 1045 | | wherever the RE matches | 1046 +------------------+-----------------------------------------------+ 1047 | ``sub()`` | Find all substrings where the RE matches, and | 1048 | | replace them with a different string | 1049 +------------------+-----------------------------------------------+ 1050 | ``subn()`` | Does the same thing as :meth:`sub`, but | 1051 | | returns the new string and the number of | 1052 | | replacements | 1053 +------------------+-----------------------------------------------+ 1054 1055 1056 Splitting Strings 1057 ----------------- 1058 1059 The :meth:`split` method of a pattern splits a string apart 1060 wherever the RE matches, returning a list of the pieces. It's similar to the 1061 :meth:`split` method of strings but provides much more generality in the 1062 delimiters that you can split by; :meth:`split` only supports splitting by 1063 whitespace or by a fixed string. As you'd expect, there's a module-level 1064 :func:`re.split` function, too. 1065 1066 1067 .. method:: .split(string [, maxsplit=0]) 1068 :noindex: 1069 1070 Split *string* by the matches of the regular expression. If capturing 1071 parentheses are used in the RE, then their contents will also be returned as 1072 part of the resulting list. If *maxsplit* is nonzero, at most *maxsplit* splits 1073 are performed. 1074 1075 You can limit the number of splits made, by passing a value for *maxsplit*. 1076 When *maxsplit* is nonzero, at most *maxsplit* splits will be made, and the 1077 remainder of the string is returned as the final element of the list. In the 1078 following example, the delimiter is any sequence of non-alphanumeric characters. 1079 :: 1080 1081 >>> p = re.compile(r'\W+') 1082 >>> p.split('This is a test, short and sweet, of split().') 1083 ['This', 'is', 'a', 'test', 'short', 'and', 'sweet', 'of', 'split', ''] 1084 >>> p.split('This is a test, short and sweet, of split().', 3) 1085 ['This', 'is', 'a', 'test, short and sweet, of split().'] 1086 1087 Sometimes you're not only interested in what the text between delimiters is, but 1088 also need to know what the delimiter was. If capturing parentheses are used in 1089 the RE, then their values are also returned as part of the list. Compare the 1090 following calls:: 1091 1092 >>> p = re.compile(r'\W+') 1093 >>> p2 = re.compile(r'(\W+)') 1094 >>> p.split('This... is a test.') 1095 ['This', 'is', 'a', 'test', ''] 1096 >>> p2.split('This... is a test.') 1097 ['This', '... ', 'is', ' ', 'a', ' ', 'test', '.', ''] 1098 1099 The module-level function :func:`re.split` adds the RE to be used as the first 1100 argument, but is otherwise the same. :: 1101 1102 >>> re.split('[\W]+', 'Words, words, words.') 1103 ['Words', 'words', 'words', ''] 1104 >>> re.split('([\W]+)', 'Words, words, words.') 1105 ['Words', ', ', 'words', ', ', 'words', '.', ''] 1106 >>> re.split('[\W]+', 'Words, words, words.', 1) 1107 ['Words', 'words, words.'] 1108 1109 1110 Search and Replace 1111 ------------------ 1112 1113 Another common task is to find all the matches for a pattern, and replace them 1114 with a different string. The :meth:`sub` method takes a replacement value, 1115 which can be either a string or a function, and the string to be processed. 1116 1117 1118 .. method:: .sub(replacement, string[, count=0]) 1119 :noindex: 1120 1121 Returns the string obtained by replacing the leftmost non-overlapping 1122 occurrences of the RE in *string* by the replacement *replacement*. If the 1123 pattern isn't found, *string* is returned unchanged. 1124 1125 The optional argument *count* is the maximum number of pattern occurrences to be 1126 replaced; *count* must be a non-negative integer. The default value of 0 means 1127 to replace all occurrences. 1128 1129 Here's a simple example of using the :meth:`sub` method. It replaces colour 1130 names with the word ``colour``:: 1131 1132 >>> p = re.compile('(blue|white|red)') 1133 >>> p.sub('colour', 'blue socks and red shoes') 1134 'colour socks and colour shoes' 1135 >>> p.sub('colour', 'blue socks and red shoes', count=1) 1136 'colour socks and red shoes' 1137 1138 The :meth:`subn` method does the same work, but returns a 2-tuple containing the 1139 new string value and the number of replacements that were performed:: 1140 1141 >>> p = re.compile('(blue|white|red)') 1142 >>> p.subn('colour', 'blue socks and red shoes') 1143 ('colour socks and colour shoes', 2) 1144 >>> p.subn('colour', 'no colours at all') 1145 ('no colours at all', 0) 1146 1147 Empty matches are replaced only when they're not adjacent to a previous match. 1148 :: 1149 1150 >>> p = re.compile('x*') 1151 >>> p.sub('-', 'abxd') 1152 '-a-b-d-' 1153 1154 If *replacement* is a string, any backslash escapes in it are processed. That 1155 is, ``\n`` is converted to a single newline character, ``\r`` is converted to a 1156 carriage return, and so forth. Unknown escapes such as ``\j`` are left alone. 1157 Backreferences, such as ``\6``, are replaced with the substring matched by the 1158 corresponding group in the RE. This lets you incorporate portions of the 1159 original text in the resulting replacement string. 1160 1161 This example matches the word ``section`` followed by a string enclosed in 1162 ``{``, ``}``, and changes ``section`` to ``subsection``:: 1163 1164 >>> p = re.compile('section{ ( [^}]* ) }', re.VERBOSE) 1165 >>> p.sub(r'subsection{\1}','section{First} section{second}') 1166 'subsection{First} subsection{second}' 1167 1168 There's also a syntax for referring to named groups as defined by the 1169 ``(?P<name>...)`` syntax. ``\g<name>`` will use the substring matched by the 1170 group named ``name``, and ``\g<number>`` uses the corresponding group number. 1171 ``\g<2>`` is therefore equivalent to ``\2``, but isn't ambiguous in a 1172 replacement string such as ``\g<2>0``. (``\20`` would be interpreted as a 1173 reference to group 20, not a reference to group 2 followed by the literal 1174 character ``'0'``.) The following substitutions are all equivalent, but use all 1175 three variations of the replacement string. :: 1176 1177 >>> p = re.compile('section{ (?P<name> [^}]* ) }', re.VERBOSE) 1178 >>> p.sub(r'subsection{\1}','section{First}') 1179 'subsection{First}' 1180 >>> p.sub(r'subsection{\g<1>}','section{First}') 1181 'subsection{First}' 1182 >>> p.sub(r'subsection{\g<name>}','section{First}') 1183 'subsection{First}' 1184 1185 *replacement* can also be a function, which gives you even more control. If 1186 *replacement* is a function, the function is called for every non-overlapping 1187 occurrence of *pattern*. On each call, the function is passed a 1188 :ref:`match object <match-objects>` argument for the match and can use this 1189 information to compute the desired replacement string and return it. 1190 1191 In the following example, the replacement function translates decimals into 1192 hexadecimal:: 1193 1194 >>> def hexrepl(match): 1195 ... "Return the hex string for a decimal number" 1196 ... value = int(match.group()) 1197 ... return hex(value) 1198 ... 1199 >>> p = re.compile(r'\d+') 1200 >>> p.sub(hexrepl, 'Call 65490 for printing, 49152 for user code.') 1201 'Call 0xffd2 for printing, 0xc000 for user code.' 1202 1203 When using the module-level :func:`re.sub` function, the pattern is passed as 1204 the first argument. The pattern may be provided as an object or as a string; if 1205 you need to specify regular expression flags, you must either use a 1206 pattern object as the first parameter, or use embedded modifiers in the 1207 pattern string, e.g. ``sub("(?i)b+", "x", "bbbb BBBB")`` returns ``'x x'``. 1208 1209 1210 Common Problems 1211 =============== 1212 1213 Regular expressions are a powerful tool for some applications, but in some ways 1214 their behaviour isn't intuitive and at times they don't behave the way you may 1215 expect them to. This section will point out some of the most common pitfalls. 1216 1217 1218 Use String Methods 1219 ------------------ 1220 1221 Sometimes using the :mod:`re` module is a mistake. If you're matching a fixed 1222 string, or a single character class, and you're not using any :mod:`re` features 1223 such as the :const:`IGNORECASE` flag, then the full power of regular expressions 1224 may not be required. Strings have several methods for performing operations with 1225 fixed strings and they're usually much faster, because the implementation is a 1226 single small C loop that's been optimized for the purpose, instead of the large, 1227 more generalized regular expression engine. 1228 1229 One example might be replacing a single fixed string with another one; for 1230 example, you might replace ``word`` with ``deed``. ``re.sub()`` seems like the 1231 function to use for this, but consider the :meth:`replace` method. Note that 1232 :func:`replace` will also replace ``word`` inside words, turning ``swordfish`` 1233 into ``sdeedfish``, but the naive RE ``word`` would have done that, too. (To 1234 avoid performing the substitution on parts of words, the pattern would have to 1235 be ``\bword\b``, in order to require that ``word`` have a word boundary on 1236 either side. This takes the job beyond :meth:`replace`'s abilities.) 1237 1238 Another common task is deleting every occurrence of a single character from a 1239 string or replacing it with another single character. You might do this with 1240 something like ``re.sub('\n', ' ', S)``, but :meth:`translate` is capable of 1241 doing both tasks and will be faster than any regular expression operation can 1242 be. 1243 1244 In short, before turning to the :mod:`re` module, consider whether your problem 1245 can be solved with a faster and simpler string method. 1246 1247 1248 match() versus search() 1249 ----------------------- 1250 1251 The :func:`match` function only checks if the RE matches at the beginning of the 1252 string while :func:`search` will scan forward through the string for a match. 1253 It's important to keep this distinction in mind. Remember, :func:`match` will 1254 only report a successful match which will start at 0; if the match wouldn't 1255 start at zero, :func:`match` will *not* report it. :: 1256 1257 >>> print re.match('super', 'superstition').span() 1258 (0, 5) 1259 >>> print re.match('super', 'insuperable') 1260 None 1261 1262 On the other hand, :func:`search` will scan forward through the string, 1263 reporting the first match it finds. :: 1264 1265 >>> print re.search('super', 'superstition').span() 1266 (0, 5) 1267 >>> print re.search('super', 'insuperable').span() 1268 (2, 7) 1269 1270 Sometimes you'll be tempted to keep using :func:`re.match`, and just add ``.*`` 1271 to the front of your RE. Resist this temptation and use :func:`re.search` 1272 instead. The regular expression compiler does some analysis of REs in order to 1273 speed up the process of looking for a match. One such analysis figures out what 1274 the first character of a match must be; for example, a pattern starting with 1275 ``Crow`` must match starting with a ``'C'``. The analysis lets the engine 1276 quickly scan through the string looking for the starting character, only trying 1277 the full match if a ``'C'`` is found. 1278 1279 Adding ``.*`` defeats this optimization, requiring scanning to the end of the 1280 string and then backtracking to find a match for the rest of the RE. Use 1281 :func:`re.search` instead. 1282 1283 1284 Greedy versus Non-Greedy 1285 ------------------------ 1286 1287 When repeating a regular expression, as in ``a*``, the resulting action is to 1288 consume as much of the pattern as possible. This fact often bites you when 1289 you're trying to match a pair of balanced delimiters, such as the angle brackets 1290 surrounding an HTML tag. The naive pattern for matching a single HTML tag 1291 doesn't work because of the greedy nature of ``.*``. :: 1292 1293 >>> s = '<html><head><title>Title</title>' 1294 >>> len(s) 1295 32 1296 >>> print re.match('<.*>', s).span() 1297 (0, 32) 1298 >>> print re.match('<.*>', s).group() 1299 <html><head><title>Title</title> 1300 1301 The RE matches the ``'<'`` in ``<html>``, and the ``.*`` consumes the rest of 1302 the string. There's still more left in the RE, though, and the ``>`` can't 1303 match at the end of the string, so the regular expression engine has to 1304 backtrack character by character until it finds a match for the ``>``. The 1305 final match extends from the ``'<'`` in ``<html>`` to the ``'>'`` in 1306 ``</title>``, which isn't what you want. 1307 1308 In this case, the solution is to use the non-greedy qualifiers ``*?``, ``+?``, 1309 ``??``, or ``{m,n}?``, which match as *little* text as possible. In the above 1310 example, the ``'>'`` is tried immediately after the first ``'<'`` matches, and 1311 when it fails, the engine advances a character at a time, retrying the ``'>'`` 1312 at every step. This produces just the right result:: 1313 1314 >>> print re.match('<.*?>', s).group() 1315 <html> 1316 1317 (Note that parsing HTML or XML with regular expressions is painful. 1318 Quick-and-dirty patterns will handle common cases, but HTML and XML have special 1319 cases that will break the obvious regular expression; by the time you've written 1320 a regular expression that handles all of the possible cases, the patterns will 1321 be *very* complicated. Use an HTML or XML parser module for such tasks.) 1322 1323 1324 Using re.VERBOSE 1325 -------------------- 1326 1327 By now you've probably noticed that regular expressions are a very compact 1328 notation, but they're not terribly readable. REs of moderate complexity can 1329 become lengthy collections of backslashes, parentheses, and metacharacters, 1330 making them difficult to read and understand. 1331 1332 For such REs, specifying the ``re.VERBOSE`` flag when compiling the regular 1333 expression can be helpful, because it allows you to format the regular 1334 expression more clearly. 1335 1336 The ``re.VERBOSE`` flag has several effects. Whitespace in the regular 1337 expression that *isn't* inside a character class is ignored. This means that an 1338 expression such as ``dog | cat`` is equivalent to the less readable ``dog|cat``, 1339 but ``[a b]`` will still match the characters ``'a'``, ``'b'``, or a space. In 1340 addition, you can also put comments inside a RE; comments extend from a ``#`` 1341 character to the next newline. When used with triple-quoted strings, this 1342 enables REs to be formatted more neatly:: 1343 1344 pat = re.compile(r""" 1345 \s* # Skip leading whitespace 1346 (?P<header>[^:]+) # Header name 1347 \s* : # Whitespace, and a colon 1348 (?P<value>.*?) # The header's value -- *? used to 1349 # lose the following trailing whitespace 1350 \s*$ # Trailing whitespace to end-of-line 1351 """, re.VERBOSE) 1352 1353 This is far more readable than:: 1354 1355 pat = re.compile(r"\s*(?P<header>[^:]+)\s*:(?P<value>.*?)\s*$") 1356 1357 1358 Feedback 1359 ======== 1360 1361 Regular expressions are a complicated topic. Did this document help you 1362 understand them? Were there parts that were unclear, or Problems you 1363 encountered that weren't covered here? If so, please send suggestions for 1364 improvements to the author. 1365 1366 The most complete book on regular expressions is almost certainly Jeffrey 1367 Friedl's Mastering Regular Expressions, published by O'Reilly. Unfortunately, 1368 it exclusively concentrates on Perl and Java's flavours of regular expressions, 1369 and doesn't contain any Python material at all, so it won't be useful as a 1370 reference for programming in Python. (The first edition covered Python's 1371 now-removed :mod:`regex` module, which won't help you much.) Consider checking 1372 it out from your library. 1373 1374 1375 .. rubric:: Footnotes 1376 1377 .. [#] Introduced in Python 2.2.2. 1378 1379