Implementando la API DiffMatchPatch de Google para Python 2/3

Quiero escribir una aplicación de diferencia simple en Python utilizando las API de Diff Match Patch de Google . Soy bastante nuevo en Python, por lo que quiero un ejemplo de cómo utilizar la API de parches Diff Match para comparar semánticamente dos párrafos de texto. No estoy muy seguro de cómo utilizar el archivo diff_match_patch.py y qué importar de él. ¡Ayuda será muy apreciada!

Además, he intentado usar difflib , pero me pareció ineficaz para comparar oraciones muy variadas. Estoy usando ubuntu 12.04 x64.

La API del parche de diferencias de Google es la misma para todos los idiomas en los que se implementa (Java, JavaScript, Dart, C ++, C #, Objective C, Lua y Python 2.xo Python 3.x). Por lo tanto, por lo general, se pueden usar fragmentos de muestra en idiomas distintos al idioma de destino para determinar qué llamadas API particulares se necesitan para varias tareas de diferencia / coincidencia / parche.

En el caso de una simple comparación “semántica” esto es lo que necesita

 import diff_match_patch textA = "the cat in the red hat" textB = "the feline in the blue hat" #create a diff_match_patch object dmp = diff_match_patch.diff_match_patch() # Depending on the kind of text you work with, in term of overall length # and complexity, you may want to extend (or here suppress) the # time_out feature dmp.Diff_Timeout = 0 # or some other value, default is 1.0 seconds # All 'diff' jobs start with invoking diff_main() diffs = dmp.diff_main(textA, textB) # diff_cleanupSemantic() is used to make the diffs array more "human" readable dmp.diff_cleanupSemantic(diffs) # and if you want the results as some ready to display HMTL snippet htmlSnippet = dmp.diff_prettyHtml(diffs) 

Una palabra sobre el procesamiento ” semántico ” por diff-match-patch
Tenga en cuenta que tal procesamiento es útil para presentar las diferencias a un espectador humano, ya que tiende a producir una lista más corta de diferencias al evitar la resincronización no relevante de los textos (cuando, por ejemplo, dos palabras distintas tienen letras comunes en su mitad). Sin embargo, los resultados producidos distan mucho de ser perfectos, ya que este procesamiento es simplemente heurística basada en la longitud de las diferencias y los patrones de superficie, etc. en lugar del procesamiento real de PNL basado en léxicos y otros dispositivos de nivel semántico.
Por ejemplo, los valores textB y textB utilizados anteriormente producen los siguientes valores “antes-y-después-diff_cleanupSemantic” para la matriz diffs

 [(0, 'the '), (-1, 'cat'), (1, 'feline'), (0, ' in the '), (-1, 'r'), (1, 'blu'), (0, 'e'), (-1, 'd'), (0, ' hat')] [(0, 'the '), (-1, 'cat'), (1, 'feline'), (0, ' in the '), (-1, 'red'), (1, 'blue'), (0, ' hat')] 

¡Bonito! La letra ‘e’ que es común a rojo y azul hace que diff_main () vea esta área del texto como cuatro ediciones, pero cleanupSemantic () se corrige como solo dos ediciones, distinguiendo muy bien los diferentes sems ‘azul’ y ‘ rojo’.

Sin embargo, si tenemos, por ejemplo,

 textA = "stackoverflow is cool" textb = "so is very cool" 

Los arreglos de antes / después producidos son:

 [(0, 's'), (-1, 'tack'), (0, 'o'), (-1, 'verflow'), (0, ' is'), (1, ' very'), (0, ' cool')] [(0, 's'), (-1, 'tackoverflow is'), (1, 'o is very'), (0, ' cool')] 

Lo que demuestra que la supuesta mejora semántica posterior puede ser “torturada” de manera indebida en comparación con la anterior . Tenga en cuenta, por ejemplo, cómo la “s” inicial se mantiene como una coincidencia y cómo la palabra “muy” agregada se mezcla con partes de la expresión “es genial”. Lo ideal es que esperemos algo como

 [(-1, 'stackoverflow'), (1, 'so'), (0, ' is '), (-1, 'very'), (0, ' cool')]