Complete Com R Ou Rr

Quando usar raw strings em expressões regulares no Python

A diferença entre usar r"pattern" e "pattern" em Python é uma daquelas coisas que todo mundo descobre tarde demais, quando já gastou trinta minutos tentando entender por que uma regex simples estava falhando. O problema central é a forma como o Python trata barras invertidas em strings normais versus raw strings, e isso tem implicações diretas no comportamento do módulo re. Raw strings são aquelas que você-prefixa com r ou R. Elas dizem ao interpretador para não processar sequências de escape dentro dos colchetes. Em strings normais, \n vira uma quebra de linha, \t vira tabulação, e \\ vira uma barra invertida única. Em raw strings, tudo que vem depois do prefixo r é tratado literalmente, exceto barras invertidas no final da string — esse é um detalhe importante que quase ninguém lembra. No contexto de expressões regulares, essa distinção é crítica. Quando você escreve re.search("\d+", texto), o Python primeiro converte \d em d (porque \d não é uma sequência de escape válida em strings normais, então o backslash é mantido mas o comportamento fica imprevisível dependendo da versão). Quando você escreve re.search(r"\d+", texto), a regex recebe exatamente a sequência \d, que o motor de regex interpreta como "qualquer dígito". A diferença é direta e, às vezes, silenciosa.

Me deparei com um caso específico recently em que uma regex para capturar caminhos de arquivo estava retornando resultados errados em produção mas funcionando localmente. O código usava "C:\\Users\\nome\\arquivo.txt" como padrão. No Windows local, o Python interpretava as barras duplas corretamente, mas no servidor Linux, onde o mesmo código tinha sido copiado com barras simples de outra fonte, a string continha \U que o Python tentava interpretar como um caractere Unicode, gerando um UnicodeError. A solução foi trocar tudo para raw strings: r"C:\Users\nome\arquivo.txt". Não usei funções de manipulação de caminho porque o objetivo era testar strings literais contra um padrão regex, e raw strings eliminaram toda essa camada de confusão. Existem situações em que raw strings simplesmente não resolvem o problema. Se o seu padrão regex precisa terminar com uma barra invertida — algo como r"\\$" para encontrar um cifrão no final de uma linha — você não pode usar raw string porque o Python rejeita barras invertidas soltas no final. Nesse caso, a alternativa é misturar: "\\\\$" ou concatenar uma raw string com uma barra normal, como r"\\" + "$". Outra limitação real é que raw strings não resolvem problemas de Legibilidade em padrões complexos. Uma regex com vinte e três grupos de captura e várias barras invertidas continua confusa independentemente do prefixo que você usar. Para quem trabalha com regex frequentemente, vale a pena conhecer algumas práticas que reduzem erros. Use sempre raw strings para padrões de regex, mesmo quando o padrão parece simples. O custo zero de adicionar o r evita metade dos bugs difíceis de rastrear. Quando precisar de barras invertidas no final do padrão, construa a string de forma explícita em vez de brincar com escape manual. E se o seu padrão for realmente complexo, considere extrair para uma constante nomeada no topo do arquivo — isso ajuda tanto você quanto qualquer outra pessoa que for ler o código depois.

O módulo re do Python também oferece re.compile(), que compila o padrão uma vez e reutiliza. Isso faz diferença significativa em loops ou quando a mesma regex é aplicada centenas de vezes. Combinado com raw strings, o resultado é código mais rápido e mais legível, sem Surpresas de escape. Regex não é a ferramenta certa para tudo. Se você está tentando parsear HTML com expressões regulares, está fazendo errado. Use um parser de HTML dedicado. Se precisa validar formato de CPF ou CNPJ, uma regex pode funcionar, mas uma função específica de validação é mais clara e mais fácil de manter. O poder das regex vem da flexibilidade, e essa mesma flexibilidade é o que as torna perigosas quando usadas além do propósito adequado.