¿Hay algún beneficio en el uso de compilación para expresiones regulares en Python?

h = re.compile('hello')
h.match('hello world')

vs

re.match('hello', 'hello world')

He tenido mucha experiencia ejecutando una expresión regular compilada 1000 veces en comparación con la compilación sobre la marcha, y no he notado ninguna diferencia perceptible. Obviamente, esto es anecdótico, y ciertamente no es un gran argumento en contra de la compilación, pero he encontrado que la diferencia es insignificante.

EDITAR: después de echar un vistazo rápido al código real de la biblioteca de Python 2.5, veo que Python compila internamente Y CACHE expresiones regulares cada vez que las usa (incluidas las llamadas a re.match()), por lo que realmente solo está cambiando CUANDO se compila la expresión regular, y no debería ' No ahorrará mucho tiempo, solo el tiempo que lleva verificar el caché (una búsqueda de clave en un dicttipo interno ).

Del módulo re.py (los comentarios son míos):

def match(pattern, string, flags=0):
    return _compile(pattern, flags).match(string)

def _compile(*key):

    # Does cache check at top of function
    cachekey = (type(key[0]),) + key
    p = _cache.get(cachekey)
    if p is not None: return p

    # ...
    # Does actual compilation on cache miss
    # ...

    # Caches compiled regex
    if len(_cache) >= _MAXCACHE:
        _cache.clear()
    _cache[cachekey] = p
    return p

Todavía a menudo precompilo expresiones regulares, pero solo para vincularlas a un nombre agradable y reutilizable, no para obtener un aumento de rendimiento esperado.

Para mí, el mayor beneficio re.compilees poder separar la definición de la expresión regular de su uso.

Incluso una expresión simple como 0|[1-9][0-9]*(entero en la base 10 sin ceros a la izquierda) puede ser lo suficientemente compleja como para que no tenga que volver a escribirla, verifique si cometió algún error tipográfico y luego tendrá que volver a verificar si hay errores al comenzar la depuración . Además, es mejor usar un nombre de variable como num o num_b10 que 0|[1-9][0-9]*.

Ciertamente es posible almacenar cadenas y pasarlas a re.match; sin embargo, eso es menos legible:

num = "..."
# then, much later:
m = re.match(num, input)

Versus compilación:

num = re.compile("...")
# then, much later:
m = num.match(input)

Aunque está bastante cerca, la última línea de la segunda se siente más natural y más simple cuando se usa repetidamente.

FWIW:

$ python -m timeit -s "import re" "re.match('hello', 'hello world')"
100000 loops, best of 3: 3.82 usec per loop

$ python -m timeit -s "import re; h=re.compile('hello')" "h.match('hello world')"
1000000 loops, best of 3: 1.26 usec per loop

por lo tanto, si va a usar mucho la misma expresión regular, puede valer la pena hacerlo re.compile(especialmente para expresiones regulares más complejas).

Se aplican los argumentos estándar contra la optimización prematura, pero no creo que realmente pierda mucha claridad / re.compilesencillez si sospecha que sus expresiones regulares pueden convertirse en un cuello de botella en el rendimiento.

Actualizar:

En Python 3.6 (sospecho que los tiempos anteriores se realizaron con Python 2.x) y el hardware 2018 (MacBook Pro), ahora obtengo los siguientes tiempos:

% python -m timeit -s "import re" "re.match('hello', 'hello world')"
1000000 loops, best of 3: 0.661 usec per loop

% python -m timeit -s "import re; h=re.compile('hello')" "h.match('hello world')"
1000000 loops, best of 3: 0.285 usec per loop

% python -m timeit -s "import re" "h=re.compile('hello'); h.match('hello world')"
1000000 loops, best of 3: 0.65 usec per loop

% python --version
Python 3.6.5 :: Anaconda, Inc.

También agregué un caso (observe las diferencias entre comillas entre las dos últimas ejecuciones) que muestra que re.match(x, ...)es literalmente [aproximadamente] equivalente a re.compile(x).match(...), es decir, parece que no ocurre el almacenamiento en caché de la representación compilada detrás de escena.

Aquí hay un caso de prueba simple:

~$ for x in 1 10 100 1000 10000 100000 1000000; do python -m timeit -n $x -s 'import re' 're.match("[0-9]{3}-[0-9]{3}-[0-9]{4}", "123-123-1234")'; done
1 loops, best of 3: 3.1 usec per loop
10 loops, best of 3: 2.41 usec per loop
100 loops, best of 3: 2.24 usec per loop
1000 loops, best of 3: 2.21 usec per loop
10000 loops, best of 3: 2.23 usec per loop
100000 loops, best of 3: 2.24 usec per loop
1000000 loops, best of 3: 2.31 usec per loop

con re.compile:

~$ for x in 1 10 100 1000 10000 100000 1000000; do python -m timeit -n $x -s 'import re' 'r = re.compile("[0-9]{3}-[0-9]{3}-[0-9]{4}")' 'r.match("123-123-1234")'; done
1 loops, best of 3: 1.91 usec per loop
10 loops, best of 3: 0.691 usec per loop
100 loops, best of 3: 0.701 usec per loop
1000 loops, best of 3: 0.684 usec per loop
10000 loops, best of 3: 0.682 usec per loop
100000 loops, best of 3: 0.694 usec per loop
1000000 loops, best of 3: 0.702 usec per loop

Por lo tanto, parece que la compilación es más rápida con este caso simple, incluso si solo coincide una vez .

Acabo de probar esto yo mismo. Para el caso simple de analizar un número de una cadena y sumarlo, usar un objeto de expresión regular compilado es aproximadamente dos veces más rápido que usar los remétodos.

Como otros han señalado, los remétodos (incluido re.compile) buscan la cadena de expresión regular en un caché de expresiones compiladas previamente. Por lo tanto, en el caso normal, el costo adicional de usar los remétodos es simplemente el costo de la búsqueda de caché.

Sin embargo, el examen del código muestra que el caché está limitado a 100 expresiones. Esto plantea la pregunta, ¿qué tan doloroso es desbordar el caché? El código contiene una interfaz interna para el compilador de expresiones regulares, re.sre_compile.compile. Si lo llamamos, omitimos el caché. Resulta ser aproximadamente dos órdenes de magnitud más lento para una expresión regular básica, como r'\w+\s+([0-9_]+)\s+\w*'.

Aquí está mi prueba:

#!/usr/bin/env python
import re
import time

def timed(func):
    def wrapper(*args):
        t = time.time()
        result = func(*args)
        t = time.time() - t
        print '%s took %.3f seconds.' % (func.func_name, t)
        return result
    return wrapper

regularExpression = r'\w+\s+([0-9_]+)\s+\w*'
testString = "average    2 never"

@timed
def noncompiled():
    a = 0
    for x in xrange(1000000):
        m = re.match(regularExpression, testString)
        a += int(m.group(1))
    return a

@timed
def compiled():
    a = 0
    rgx = re.compile(regularExpression)
    for x in xrange(1000000):
        m = rgx.match(testString)
        a += int(m.group(1))
    return a

@timed
def reallyCompiled():
    a = 0
    rgx = re.sre_compile.compile(regularExpression)
    for x in xrange(1000000):
        m = rgx.match(testString)
        a += int(m.group(1))
    return a


@timed
def compiledInLoop():
    a = 0
    for x in xrange(1000000):
        rgx = re.compile(regularExpression)
        m = rgx.match(testString)
        a += int(m.group(1))
    return a

@timed
def reallyCompiledInLoop():
    a = 0
    for x in xrange(10000):
        rgx = re.sre_compile.compile(regularExpression)
        m = rgx.match(testString)
        a += int(m.group(1))
    return a

r1 = noncompiled()
r2 = compiled()
r3 = reallyCompiled()
r4 = compiledInLoop()
r5 = reallyCompiledInLoop()
print "r1 = ", r1
print "r2 = ", r2
print "r3 = ", r3
print "r4 = ", r4
print "r5 = ", r5
</pre>
And here is the output on my machine:
<pre>
$ regexTest.py 
noncompiled took 4.555 seconds.
compiled took 2.323 seconds.
reallyCompiled took 2.325 seconds.
compiledInLoop took 4.620 seconds.
reallyCompiledInLoop took 4.074 seconds.
r1 =  2000000
r2 =  2000000
r3 =  2000000
r4 =  2000000
r5 =  20000

Los métodos 'reallyCompiled' usan la interfaz interna, que evita el caché. Tenga en cuenta que el que se compila en cada iteración de bucle solo se repite 10,000 veces, no un millón.

Estoy de acuerdo con Honest Abe en que los match(...)ejemplos dados son diferentes. No son comparaciones individuales y, por lo tanto, los resultados varían. Para simplificar mi respuesta, uso A, B, C, D para esas funciones en cuestión. Oh sí, estamos tratando con 4 funciones en re.pylugar de 3.

Ejecutando este fragmento de código:

h = re.compile('hello')                   # (A)
h.match('hello world')                    # (B)

es lo mismo que ejecutar este código:

re.match('hello', 'hello world')          # (C)

Porque, cuando se mira en la fuente re.py, (A + B) significa:

h = re._compile('hello')                  # (D)
h.match('hello world')

y (C) es en realidad:

re._compile('hello').match('hello world')

Entonces, (C) no es lo mismo que (B). De hecho, (C) llama (B) después de llamar (D), que también es llamado por (A). En otras palabras, (C) = (A) + (B). Por lo tanto, comparar (A + B) dentro de un ciclo tiene el mismo resultado que (C) dentro de un ciclo.

George ha regexTest.pydemostrado esto por nosotros.

noncompiled took 4.555 seconds.           # (C) in a loop
compiledInLoop took 4.620 seconds.        # (A + B) in a loop
compiled took 2.323 seconds.              # (A) once + (B) in a loop

El interés de todos es cómo obtener el resultado de 2.323 segundos. Para asegurarnos de que compile(...)solo se nos llame una vez, debemos almacenar el objeto regex compilado en la memoria. Si estamos usando una clase, podríamos almacenar el objeto y reutilizarlo cada vez que se llama a nuestra función.

class Foo:
    regex = re.compile('hello')
    def my_function(text)
        return regex.match(text)

Si no estamos usando la clase (que es mi solicitud hoy), entonces no tengo ningún comentario. Todavía estoy aprendiendo a usar la variable global en Python, y sé que la variable global es algo malo.

Un punto más, creo que usar el (A) + (B)enfoque tiene una ventaja. Aquí hay algunos hechos que observé (corrígeme si me equivoco):

1. Llama a A una vez, realizará una búsqueda en la _cachesiguiente sre_compile.compile()para crear un objeto regex. Llama a A dos veces, realizará dos búsquedas y una compilación (porque el objeto regex está en caché).

2. Si el _cacheenjuague en el medio, entonces el objeto regex se libera de la memoria y Python necesita compilarse nuevamente. (Alguien sugiere que Python no se recompilará).

3. Si mantenemos el objeto regex usando (A), el objeto regex todavía entrará en _cache y se enjuagará de alguna manera. Pero nuestro código tiene una referencia y el objeto regex no se liberará de la memoria. Esos, Python no necesita compilar nuevamente.

4. Las diferencias de 2 segundos en la prueba de George compiledInLoop vs compilado es principalmente el tiempo requerido para construir la clave y buscar en la caché. No significa el tiempo de compilación de expresiones regulares.

5. La prueba de compilación realmente de George muestra lo que sucede si realmente vuelve a hacer la compilación cada vez: será 100 veces más lento (redujo el ciclo de 1,000,000 a 10,000).

Estos son los únicos casos en que (A + B) es mejor que (C):

1. Si podemos almacenar en caché una referencia del objeto regex dentro de una clase.
2. Si necesitamos llamar a (B) repetidamente (dentro de un ciclo o varias veces), debemos almacenar en caché la referencia al objeto regex fuera del ciclo.

Caso que (C) es lo suficientemente bueno:

1. No podemos almacenar en caché una referencia.
2. Solo lo usamos de vez en cuando.
3. En general, no tenemos demasiadas expresiones regulares (supongamos que la compilada nunca se descarga)

Solo un resumen, aquí están los ABC:

h = re.compile('hello')                   # (A)
h.match('hello world')                    # (B)
re.match('hello', 'hello world')          # (C)

Gracias por leer.

Principalmente, hay poca diferencia si usa re.compile o no. Internamente, todas las funciones se implementan en términos de un paso de compilación:

def match(pattern, string, flags=0):
    return _compile(pattern, flags).match(string)

def fullmatch(pattern, string, flags=0):
    return _compile(pattern, flags).fullmatch(string)

def search(pattern, string, flags=0):
    return _compile(pattern, flags).search(string)

def sub(pattern, repl, string, count=0, flags=0):
    return _compile(pattern, flags).sub(repl, string, count)

def subn(pattern, repl, string, count=0, flags=0):
    return _compile(pattern, flags).subn(repl, string, count)

def split(pattern, string, maxsplit=0, flags=0):
    return _compile(pattern, flags).split(string, maxsplit)

def findall(pattern, string, flags=0):
    return _compile(pattern, flags).findall(string)

def finditer(pattern, string, flags=0):
    return _compile(pattern, flags).finditer(string)

Además, re.compile () omite la lógica indirecta y de almacenamiento en caché adicionales:

_cache = {}

_pattern_type = type(sre_compile.compile("", 0))

_MAXCACHE = 512
def _compile(pattern, flags):
    # internal: compile pattern
    try:
        p, loc = _cache[type(pattern), pattern, flags]
        if loc is None or loc == _locale.setlocale(_locale.LC_CTYPE):
            return p
    except KeyError:
        pass
    if isinstance(pattern, _pattern_type):
        if flags:
            raise ValueError(
                "cannot process flags argument with a compiled pattern")
        return pattern
    if not sre_compile.isstring(pattern):
        raise TypeError("first argument must be string or compiled pattern")
    p = sre_compile.compile(pattern, flags)
    if not (flags & DEBUG):
        if len(_cache) >= _MAXCACHE:
            _cache.clear()
        if p.flags & LOCALE:
            if not _locale:
                return p
            loc = _locale.setlocale(_locale.LC_CTYPE)
        else:
            loc = None
        _cache[type(pattern), pattern, flags] = p, loc
    return p

Además del pequeño beneficio de velocidad del uso de re.compile , a las personas también les gusta la legibilidad que resulta de nombrar especificaciones de patrones potencialmente complejas y separarlas de la lógica comercial donde se aplican:

#### Patterns ############################################################
number_pattern = re.compile(r'\d+(\.\d*)?')    # Integer or decimal number
assign_pattern = re.compile(r':=')             # Assignment operator
identifier_pattern = re.compile(r'[A-Za-z]+')  # Identifiers
whitespace_pattern = re.compile(r'[\t ]+')     # Spaces and tabs

#### Applications ########################################################

if whitespace_pattern.match(s): business_logic_rule_1()
if assign_pattern.match(s): business_logic_rule_2()

Tenga en cuenta que otro encuestado creía incorrectamente que los archivos pyc almacenaban patrones compilados directamente; sin embargo, en realidad se reconstruyen cada vez que se carga el PYC:

>>> from dis import dis
>>> with open('tmp.pyc', 'rb') as f:
        f.read(8)
        dis(marshal.load(f))

  1           0 LOAD_CONST               0 (-1)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (re)
              9 STORE_NAME               0 (re)

  3          12 LOAD_NAME                0 (re)
             15 LOAD_ATTR                1 (compile)
             18 LOAD_CONST               2 ('[aeiou]{2,5}')
             21 CALL_FUNCTION            1
             24 STORE_NAME               2 (lc_vowels)
             27 LOAD_CONST               1 (None)
             30 RETURN_VALUE

El desmontaje anterior proviene del archivo PYC que tmp.pycontiene:

import re
lc_vowels = re.compile(r'[aeiou]{2,5}')

En general, creo que es más fácil usar banderas (al menos más fácil de recordar cómo), como re.Icuando se compilan patrones que usar banderas en línea.

>>> foo_pat = re.compile('foo',re.I)
>>> foo_pat.findall('some string FoO bar')
['FoO']

vs

>>> re.findall('(?i)foo','some string FoO bar')
['FoO']

Usando los ejemplos dados:

h = re.compile('hello')
h.match('hello world')

El método de coincidencia en el ejemplo anterior no es el mismo que se usa a continuación:

re.match('hello', 'hello world')

re.compile () devuelve un objeto de expresión regular , lo que significa que hes un objeto regex.

El objeto regex tiene su propio método de coincidencia con los parámetros opcionales pos y endpos :

regex.match(string[, pos[, endpos]])

pos

El segundo parámetro opcional pos da un índice en la cadena donde comenzará la búsqueda; su valor predeterminado es 0. Esto no es completamente equivalente a cortar la cadena; el '^'carácter del patrón coincide en el comienzo real de la cadena y en las posiciones justo después de una nueva línea, pero no necesariamente en el índice donde comenzará la búsqueda.

endpos

El parámetro opcional endpos limita qué tan lejos se buscará la cadena; será como si la cadena tuviera caracteres endpos largos, por lo que solo se buscarán coincidencias entre los caracteres de pos a endpos - 1. Si endpos es menor que pos , no se encontrará coincidencia; de lo contrario, si rx es un objeto de expresión regular compilado, rx.search(string, 0, 50)es equivalente a rx.search(string[:50], 0).

Los métodos de búsqueda , findall y finditer del objeto regex también admiten estos parámetros.

re.match(pattern, string, flags=0)no los admite como se puede ver,
ni su búsqueda , findall y finditer homólogos.

Un objeto de coincidencia tiene atributos que complementan estos parámetros:

match.pos

El valor de pos que se pasó al método search () o match () de un objeto regex. Este es el índice en la cadena en la que el motor RE comenzó a buscar una coincidencia.

match.endpos

El valor de endpos que se pasó al método search () o match () de un objeto regex. Este es el índice en la cadena más allá del cual el motor RE no irá.

Un objeto regex tiene dos atributos únicos, posiblemente útiles:

regex.groups

El número de grupos de captura en el patrón.

regex.groupindex

Un diccionario que asigna cualquier nombre de grupo simbólico definido por (? P) a números de grupo. El diccionario está vacío si no se utilizaron grupos simbólicos en el patrón.

Y finalmente, un objeto de coincidencia tiene este atributo:

match.re

El objeto de expresión regular cuyo método match () o search () produjo esta instancia de coincidencia.

Dejando a un lado la diferencia de rendimiento, el uso de re.compile y el objeto compilado de expresión regular para hacer coincidir (cualesquiera que sean las operaciones relacionadas con la expresión regular) aclara la semántica del tiempo de ejecución de Python.

Tuve una experiencia dolorosa de depurar un código simple:

compare = lambda s, p: re.match(p, s)

y luego usaría comparar en

[x for x in data if compare(patternPhrases, x[columnIndex])]

donde patternPhrasesse supone que es una variable que contiene una cadena de expresión regular,x[columnIndex] es una variable que contiene una cadena.

Tuve problemas para que patternPhrasesno coincida con alguna cadena esperada!

Pero si usé el formulario re.compile:

compare = lambda s, p: p.match(s)

entonces en

[x for x in data if compare(patternPhrases, x[columnIndex])]

Python se habría quejado de que "la cadena no tiene el atributo de coincidencia", ya que mediante el mapeo de argumentos posicionales compare, ¡ x[columnIndex]se usa como expresión regular !, cuando realmente quise decir

compare = lambda p, s: p.match(s)

En mi caso, el uso de re.compile es más explícito del propósito de la expresión regular, cuando su valor está oculto a simple vista, por lo que podría obtener más ayuda de la comprobación de tiempo de ejecución de Python.

Entonces, la moraleja de mi lección es que cuando la expresión regular no es solo una cadena literal, entonces debería usar re.compile para permitir que Python me ayude a afirmar mi suposición.

Hay una ventaja adicional de usar re.compile (), en forma de agregar comentarios a mis patrones de expresiones regulares usando re.VERBOSE

pattern = '''
hello[ ]world    # Some info on my pattern logic. [ ] to recognize space
'''

re.search(pattern, 'hello world', re.VERBOSE)

Aunque esto no afecta la velocidad de ejecución de su código, me gusta hacerlo de esta manera, ya que es parte de mi hábito de comentar. No me gusta pasar tiempo tratando de recordar la lógica detrás de mi código 2 meses después cuando quiero hacer modificaciones.

De acuerdo con la documentación de Python :

La secuencia

prog = re.compile(pattern)
result = prog.match(string)

es equivalente a

result = re.match(pattern, string)

pero usando re.compile() y guardar el objeto de expresión regular resultante para su reutilización es más eficiente cuando la expresión se usará varias veces en un solo programa.

Entonces, mi conclusión es que si va a hacer coincidir el mismo patrón para muchos textos diferentes, es mejor que lo precompile.

Curiosamente, la compilación me resulta más eficiente (Python 2.5.2 en Win XP):

import re
import time

rgx = re.compile('(\w+)\s+[0-9_]?\s+\w*')
str = "average    2 never"
a = 0

t = time.time()

for i in xrange(1000000):
    if re.match('(\w+)\s+[0-9_]?\s+\w*', str):
    #~ if rgx.match(str):
        a += 1

print time.time() - t

Ejecutando el código anterior una vez como está, y una vez con las dos iflíneas comentadas al revés, la expresión regular compilada es dos veces más rápida

Realicé esta prueba antes de tropezar con la discusión aquí. Sin embargo, después de ejecutarlo, pensé que al menos publicaría mis resultados.

Robé y bastardeé el ejemplo en "Dominar expresiones regulares" de Jeff Friedl. Esto está en un macbook con OSX 10.6 (2Ghz intel core 2 duo, 4GB ram). La versión de Python es 2.6.1.

Ejecutar 1 - usando re.compile

import re 
import time 
import fpformat
Regex1 = re.compile('^(a|b|c|d|e|f|g)+$') 
Regex2 = re.compile('^[a-g]+$')
TimesToDo = 1000
TestString = "" 
for i in range(1000):
    TestString += "abababdedfg"
StartTime = time.time() 
for i in range(TimesToDo):
    Regex1.search(TestString) 
Seconds = time.time() - StartTime 
print "Alternation takes " + fpformat.fix(Seconds,3) + " seconds"

StartTime = time.time() 
for i in range(TimesToDo):
    Regex2.search(TestString) 
Seconds = time.time() - StartTime 
print "Character Class takes " + fpformat.fix(Seconds,3) + " seconds"

Alternation takes 2.299 seconds
Character Class takes 0.107 seconds

Ejecutar 2: no utiliza re.compile

import re 
import time 
import fpformat

TimesToDo = 1000
TestString = "" 
for i in range(1000):
    TestString += "abababdedfg"
StartTime = time.time() 
for i in range(TimesToDo):
    re.search('^(a|b|c|d|e|f|g)+$',TestString) 
Seconds = time.time() - StartTime 
print "Alternation takes " + fpformat.fix(Seconds,3) + " seconds"

StartTime = time.time() 
for i in range(TimesToDo):
    re.search('^[a-g]+$',TestString) 
Seconds = time.time() - StartTime 
print "Character Class takes " + fpformat.fix(Seconds,3) + " seconds"

Alternation takes 2.508 seconds
Character Class takes 0.109 seconds

Esta respuesta puede llegar tarde, pero es un hallazgo interesante. El uso de la compilación realmente puede ahorrarle tiempo si planea usar la expresión regular varias veces (esto también se menciona en los documentos). A continuación puede ver que el uso de una expresión regular compilada es la más rápida cuando se llama directamente al método de coincidencia. pasar un regex compilado a re.match lo hace aún más lento y pasar re.match con la cadena de patrones está en algún lugar en el medio.

>>> ipr = r'\D+((([0-2][0-5]?[0-5]?)\.){3}([0-2][0-5]?[0-5]?))\D+'
>>> average(*timeit.repeat("re.match(ipr, 'abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
1.5077415757028423
>>> ipr = re.compile(ipr)
>>> average(*timeit.repeat("re.match(ipr, 'abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
1.8324008992184038
>>> average(*timeit.repeat("ipr.match('abcd100.10.255.255 ')", globals={'ipr': ipr, 're': re}))
0.9187896518778871

Además de la actuación.

El uso compileme ayuda a distinguir los conceptos de
1. módulo (re) ,
2. objeto regex
3. objeto de coincidencia
Cuando comencé a aprender regex

#regex object
regex_object = re.compile(r'[a-zA-Z]+')
#match object
match_object = regex_object.search('1.Hello')
#matching content
match_object.group()
output:
Out[60]: 'Hello'
V.S.
re.search(r'[a-zA-Z]+','1.Hello').group()
Out[61]: 'Hello'

Como complemento, hice una exhaustiva hoja de trucos del módulo repara su referencia.

regex = {
'brackets':{'single_character': ['[]', '.', {'negate':'^'}],
            'capturing_group' : ['()','(?:)', '(?!)' '|', '\\', 'backreferences and named group'],
            'repetition'      : ['{}', '*?', '+?', '??', 'greedy v.s. lazy ?']},
'lookaround' :{'lookahead'  : ['(?=...)', '(?!...)'],
            'lookbehind' : ['(?<=...)','(?<!...)'],
            'caputuring' : ['(?P<name>...)', '(?P=name)', '(?:)'],},
'escapes':{'anchor'          : ['^', '\b', '$'],
          'non_printable'   : ['\n', '\t', '\r', '\f', '\v'],
          'shorthand'       : ['\d', '\w', '\s']},
'methods': {['search', 'match', 'findall', 'finditer'],
              ['split', 'sub']},
'match_object': ['group','groups', 'groupdict','start', 'end', 'span',]
}

Realmente respeto todas las respuestas anteriores. Desde mi opinion si! Seguro que vale la pena usar re.compile en lugar de compilar la expresión regular, una y otra vez, cada vez.

El uso de re.compile hace que su código sea más dinámico, ya que puede llamar a la expresión regular ya compilada, en lugar de volver a compilar de nuevo. Esto te beneficia en los casos:

1. Esfuerzos del procesador
2. Complejidad del tiempo.
3. Hace que regex sea universal (se puede usar en findall, búsqueda, coincidencia)
4. Y hace que su programa se vea genial.

Ejemplo:

  example_string = "The room number of her room is 26A7B."
  find_alpha_numeric_string = re.compile(r"\b\w+\b")

Utilizando en Findall

 find_alpha_numeric_string.findall(example_string)

Usando en la búsqueda

  find_alpha_numeric_string.search(example_string)

Del mismo modo, puede usarlo para: Emparejar y sustituir

Esta es una buena pregunta. A menudo ves que la gente usa re.compile sin razón. Reduce la legibilidad. Pero seguro que hay muchas veces que se requiere precompilar la expresión. Como cuando lo usas repetidas veces en un bucle o algo así.

Es como todo sobre programación (todo en la vida en realidad). Aplica el sentido común.

(meses después) es fácil agregar su propio caché alrededor de re.match, o cualquier otra cosa,

""" Re.py: Re.match = re.match + cache  
    efficiency: re.py does this already (but what's _MAXCACHE ?)
    readability, inline / separate: matter of taste
"""

import re

cache = {}
_re_type = type( re.compile( "" ))

def match( pattern, str, *opt ):
    """ Re.match = re.match + cache re.compile( pattern ) 
    """
    if type(pattern) == _re_type:
        cpat = pattern
    elif pattern in cache:
        cpat = cache[pattern]
    else:
        cpat = cache[pattern] = re.compile( pattern, *opt )
    return cpat.match( str )

# def search ...

Un wibni, ¿no sería bueno si: cachehint (size =), cacheinfo () -> size, hits, nclear ...

He tenido mucha experiencia ejecutando una expresión regular compilada 1000 veces en comparación con la compilación sobre la marcha, y no he notado ninguna diferencia perceptible

Los votos sobre la respuesta aceptada llevan a suponer que lo que dice @Triptych es cierto para todos los casos. Esto no necesariamente es cierto. Una gran diferencia es cuando tiene que decidir si acepta una cadena de expresiones regulares o un objeto de expresiones regulares compilado como parámetro de una función:

>>> timeit.timeit(setup="""
... import re
... f=lambda x, y: x.match(y)       # accepts compiled regex as parameter
... h=re.compile('hello')
... """, stmt="f(h, 'hello world')")
0.32881879806518555
>>> timeit.timeit(setup="""
... import re
... f=lambda x, y: re.compile(x).match(y)   # compiles when called
... """, stmt="f('hello', 'hello world')")
0.809190034866333

Siempre es mejor compilar sus expresiones regulares en caso de que necesite reutilizarlas.

Tenga en cuenta que el ejemplo en el tiempo anterior simula la creación de un objeto regex compilado una vez en el momento de la importación frente a "sobre la marcha" cuando es necesario para una coincidencia.

Como respuesta alternativa, como veo que no se ha mencionado antes, seguiré citando los documentos de Python 3 :

¿Debería usar estas funciones de nivel de módulo, o debería obtener el patrón y llamar a sus métodos usted mismo? Si está accediendo a una expresión regular dentro de un ciclo, precompilarla ahorrará algunas llamadas a funciones. Fuera de los bucles, no hay mucha diferencia gracias al caché interno.

Aquí hay un ejemplo donde el uso re.compilees más de 50 veces más rápido, según lo solicitado .

El punto es el mismo que hice en el comentario anterior, es decir, usar re.compilepuede ser una ventaja significativa cuando su uso es tal que no se beneficia mucho de la memoria caché de compilación. Esto sucede al menos en un caso particular (que me encontré en la práctica), es decir, cuando todo lo siguiente es cierto:

• Tiene muchos patrones de expresiones regulares (más de re._MAXCACHE, cuyo valor predeterminado es es actualmente 512), y
• usa estas expresiones regulares muchas veces, y
• Sus usos consecutivos del mismo patrón están separados por más que re._MAXCACHEotras expresiones regulares intermedias, de modo que cada uno se vacía del caché entre usos consecutivos.

import re
import time

def setup(N=1000):
    # Patterns 'a.*a', 'a.*b', ..., 'z.*z'
    patterns = [chr(i) + '.*' + chr(j)
                    for i in range(ord('a'), ord('z') + 1)
                    for j in range(ord('a'), ord('z') + 1)]
    # If this assertion below fails, just add more (distinct) patterns.
    # assert(re._MAXCACHE < len(patterns))
    # N strings. Increase N for larger effect.
    strings = ['abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz'] * N
    return (patterns, strings)

def without_compile():
    print('Without re.compile:')
    patterns, strings = setup()
    print('searching')
    count = 0
    for s in strings:
        for pat in patterns:
            count += bool(re.search(pat, s))
    return count

def without_compile_cache_friendly():
    print('Without re.compile, cache-friendly order:')
    patterns, strings = setup()
    print('searching')
    count = 0
    for pat in patterns:
        for s in strings:
            count += bool(re.search(pat, s))
    return count

def with_compile():
    print('With re.compile:')
    patterns, strings = setup()
    print('compiling')
    compiled = [re.compile(pattern) for pattern in patterns]
    print('searching')
    count = 0
    for s in strings:
        for regex in compiled:
            count += bool(regex.search(s))
    return count

start = time.time()
print(with_compile())
d1 = time.time() - start
print(f'-- That took {d1:.2f} seconds.\n')

start = time.time()
print(without_compile_cache_friendly())
d2 = time.time() - start
print(f'-- That took {d2:.2f} seconds.\n')

start = time.time()
print(without_compile())
d3 = time.time() - start
print(f'-- That took {d3:.2f} seconds.\n')

print(f'Ratio: {d3/d1:.2f}')

Ejemplo de salida que obtengo en mi computadora portátil (Python 3.7.7):

With re.compile:
compiling
searching
676000
-- That took 0.33 seconds.

Without re.compile, cache-friendly order:
searching
676000
-- That took 0.67 seconds.

Without re.compile:
searching
676000
-- That took 23.54 seconds.

Ratio: 70.89

No me molesté timeitporque la diferencia es muy marcada, pero cada vez obtengo números cualitativamente similares. Tenga en cuenta que incluso sin re.compileusar la misma expresión regular varias veces y pasar a la siguiente no fue tan malo (solo alrededor de 2 veces más lento que con re.compile), pero en el otro orden (recorrer muchas expresiones regulares), es significativamente peor , como se esperaba. Además, el aumento del tamaño de cache trabaja demasiado: simplemente poniendo re._MAXCACHE = len(patterns)en setup()más arriba (por supuesto que no recomiendo hacer este tipo de cosas en la producción como nombres con guiones son convencionalmente “privado”) deja caer el ~ 23 segundos de nuevo a ~ 0,7 segundos, lo que también coincide con nuestro entendimiento.

Las expresiones regulares se compilan antes de usarse cuando se usa la segunda versión. Si va a ejecutarlo muchas veces, definitivamente es mejor compilarlo primero. Si no compila cada vez que coincida con uno, está bien.

Legibilidad / preferencia de carga cognitiva

Para mí, la ganancia principal es que solo necesito recordar y leer una forma de la sintaxis de la API de expresiones regulares complicadas: la <compiled_pattern>.method(xxx)forma en lugar de eso y lare.func(<pattern>, xxx) forma.

los re.compile(<pattern>) es un poco extra repetitivo, cierto.

Pero en lo que respecta a la expresión regular, es poco probable que ese paso de compilación adicional sea una gran causa de carga cognitiva. Y de hecho, en patrones complicados, incluso puede obtener claridad al separar la declaración de cualquier método de expresión regular que luego invoque.

Primero tiendo a ajustar patrones complicados en un sitio web como Regex101, o incluso en un script de prueba mínimo por separado, luego los incluyo en mi código, por lo que separar la declaración de su uso también se adapta a mi flujo de trabajo.

Me gustaría motivar que la compilación previa sea ventajosa tanto conceptual como "alfabetizada" (como en "programación alfabetizada"). Echa un vistazo a este fragmento de código:

from re import compile as _Re

class TYPO:

  def text_has_foobar( self, text ):
    return self._text_has_foobar_re_search( text ) is not None
  _text_has_foobar_re_search = _Re( r"""(?i)foobar""" ).search

TYPO = TYPO()

en su solicitud, escribiría:

from TYPO import TYPO
print( TYPO.text_has_foobar( 'FOObar ) )

Esto es tan simple en términos de funcionalidad como puede ser. porque este es un ejemplo tan corto, combiné la forma de obtener _text_has_foobar_re_searchtodo en una línea. La desventaja de este código es que ocupa un poco de memoria durante la vida útil del TYPOobjeto de la biblioteca; La ventaja es que al realizar una búsqueda de foobar, se saldrá con dos llamadas a funciones y dos búsquedas de diccionario de clase. cuántas expresiones regulares se almacenan en caché rey la sobrecarga de ese caché son irrelevantes aquí.

Compare esto con el estilo más habitual, a continuación:

import re

class Typo:

  def text_has_foobar( self, text ):
    return re.compile( r"""(?i)foobar""" ).search( text ) is not None

En la aplicacion:

typo = Typo()
print( typo.text_has_foobar( 'FOObar ) )

Admito que mi estilo es muy inusual para Python, tal vez incluso discutible. sin embargo, en el ejemplo que coincide más estrechamente con la forma en que se usa principalmente Python, para hacer una sola coincidencia, debemos crear una instancia de un objeto, realizar búsquedas de diccionario de tres instancias y realizar tres llamadas a funciones; Además, podríamos entrar enre problemas de almacenamiento caché al usar más de 100 expresiones regulares. Además, la expresión regular se oculta dentro del cuerpo del método, que la mayoría de las veces no es una buena idea.

se diga que cada subconjunto de medidas --- declaraciones de importación dirigidas y con alias; métodos con alias cuando corresponda; La reducción de llamadas a funciones y búsquedas en el diccionario de objetos puede ayudar a reducir la complejidad computacional y conceptual.

Tengo entendido que esos dos ejemplos son efectivamente equivalentes. La única diferencia es que en el primero, puede reutilizar la expresión regular compilada en otro lugar sin hacer que se vuelva a compilar.

Aquí hay una referencia para usted: http://diveintopython3.ep.io/refactoring.html

Llamar a la función de búsqueda del objeto de patrón compilado con la cadena 'M' logra lo mismo que llamar a re.search con la expresión regular y la cadena 'M'. Solo que mucho, mucho más rápido. (De hecho, la función re.search simplemente compila la expresión regular y llama al método de búsqueda del objeto de patrón resultante por usted).