Tené en cuenta que haciendo las instrucciones en español en el mismo archivo README de él, no vas a poder hacerle una pr, si ese fuera tu interés.

No terminamos de entender esta tabla, si hay una diferencia entre el uso de los iguales y los casos en que no hay un igual.

Si querés hacerle la PR a Warstadt, correspondería que no pises tu lexicon con el de él. Quizás conviene que llames lexicon_en al de él y lexicon_es al tuyo y que dejes como versión por defecto el de él en lugar del tuyo.

i.e. es un latinismo crudo, así que técnicamente debería ir por normativa en itálicas. No es, de todos modos, una normativa muy extendida, así que queda a tu criterio. La normativa que abolió la tilde de "este" en todos sus usos sí está bastante aceptada, así que eso sugeriría cambiarlo.

Esta variable no se usa nunca. Se puede borrar. Sé que no la creaste vos, pero de todos modos es innecesaria.

Creo que sería mejor que manual_derivation esté en algún archivo dentro de derivations. Es cierto que antes esta función estaba acá, pero porque no había mucho más. Si ahora va haber más funcionalidad incluida, por ahí se puede agregar un archivo dentro de derivations que tenga las funciones que ejecuten manual_derivation y automated_derivation (o parse).

Entiendo que desde acá hasta la línea 22 la intención es imprimir los archivos de gramáticas disponibles indicando cuál está seleccionado actualmente y cuántos son en general. La implementación que está ahora funciona y no está mal, pero te dejo un comentario para seguir pensando.
Fijate que ahora estás esjecutando 3 for loops: uno para modificar el orden de la lista y que el archivo seleccionado por defecto esté primero, otro para construir el diccionario de indexes y, por último, un tercero para imprimir. Eso se podría hacer usando un solo for loop:

print(f'{len(filenames)} grammar(s) found: ')
    indexes = dict()
    for i, file in enumerate(filenames):
        if file == filename:
            print(f'{i}: {file} (current)')
        else:
            print(f'{i}: {file}') 
        indexes[i] = file

Perdés la posibilidad de que el archivo seleccionado por defecto quede arriba del todo, pero por ahí no es tan grave. Pensalo.

Consideraría la posibilidad de filtrar por extensión de archivo. Pensá que si mañana querés agregarun README.mda la carpeta data para que futuros usuarios sepan cómo construir una gramática, ese README aparecería listado porque es un file. Si lo filtrás por extensión, reducís ese riesgo.

Creo que todo esto se podría englobar dentro de una única opción select_grammar que implementase esta lógica de selección. Sería como agregarle una capa más después de print_grammars, y que main llame directo a la función seleccionadora. Evaluaría hacer lo mismo con el AssertionError de la opción 1.

Perdón, quise poner función en lugar de opción y por algún motivo no puedo editar el comentario.

Ver comentario en línea 8.

Si querés que por defecto file_name sea igual a "lexicon.xml", podés poner directamente:

De esta forma, si el usuario indica otro file_name, se va a tomar el del usuario. Y, si no, se toma "lexicon.xml". Con esto podés borrar las líneas 17-20.

Hola Macarena. Entiendo que sería más prolijo eliminar la variable filename, y que hay un global filename innecesario. Lo que no me queda claro es: al hacer este cambio, si el usuario no instancia directamente el Lexicon, ¿cómo puede saber la función manual_derivation, sin una variable que contenga el nombre del archivo, si pasarle o no un argumento a Lexicon()? El código actual también usa esa variable para mostrar en pantalla el nombre del archivo en uso.
Sí se me ocurre que podría conservar esta variable, sólo que con valor None. Y luego un if isinstance(filename, type(None)): etc.
Perfecto el resto de los comentarios.
Gracias!

Hola, Facundo. Estoy un poco desorientada. ¿Puede ser que esta respuesta sea para el comentario donde te sugiero borrar las variables con global? La función manual_derivation está definida en el archivo main.py. Ahí, en la línea 5 ya estás definiendo la variable filename y asinándole un valor (lexicon.xml). En la línea 26 de ese mismo archivo se instancia la clase Lexicon con ese filename. No sé si con esto respondo a tu comentario o iba por otro lado. Avisame sin problemas y lo podemos seguir conversando.

Mi comentario era una duda sobre la "plausibilidad" de modificar el constructor de la clase Lexicon y eliminar la variable filename de main.py (pero tal vez entendí mal la propuesta). Y decía, en ese caso, ¿cómo va a saber la función manual_derivation si pasarle un parámetro o no a la clase (y que tome el nombre del archivo por defecto)?

En cuanto a las dos líneas global filename, veo bien que la que se encuentra en la función print_grammars() no tiene mucho sentido. Pero en la función main() la agregué con la idea de poder modificar el valor de la variable desde dentro de la función (siguiendo el último ejemplo de esta explicación). Y a su vez está definida de manera global (en la línea 5) para que su valor pueda ser accesible para print_grammars(), aunque acá la redefinición como global sea innecesaria.

Comprendido lo de las dos clases Derivation que comentabas más abajo.

Gracias!

Hola, Facundo. Claro. Creo que algunas cosas me quedan más claras ahora.

Respecto de main.py, es cierto que si no lo hacés con global, no podés modificar la variable que está definida afuera. No me había dado cuenta. Disculpame. Una alternativa para todo eso podría ser cambiar la línea 8 por filename="lexicon.xml" (dentro de la función main()) y que la función print_grammars() tome ese valor. Te sugiero eso porque eso te permitiría, si quisieras, definir la función print_grammars() en otro archivo si quisieras (para que no te quede un main.py con tanta lógica) y, por otro lado, evitar el extraño diseño al tener una función que toma una variable definida externamente mientras que otras funciones necesitan tomar ese valor como un parámetro. En caso de que prefirieses seguir con el global, por ahí consideraría moverlo al flujo dentro del elif para el valor 3, dado que solo ahí la función main() cambia su valor. Antes no. Esto último, asumiento que dejás la variable definida también en la línea 5 tal como esta.

En cuando a la definición de la clase Lexicon, no me termina de quedar clara tu duda. La sugerencia que te hago es para evitar el flujo de si file_name es None. Cuando se quiere definir una variable con un valor por defecto, se suele hacer como te sugiero. La función manual_derivation() debería pasarle el valor del filename de todos modos porque, si el usuario elige uno que no es el que se indica por defecto, está bien pasarlo. Y si es el por defecto, no está mal tampoco. No termino de entender la lógica externa con el None que planteas (dentro de manual_derivation() si no entiendo mal).

Si querés, podemos arreglar para hablarlo por videollamada dos minutos porque quizá es que no estoy atando todos los cabos correctamente.

Hola Macarena! Perfecto, parece mucho más sensato definir la variable filename dentro de main() y pasársela a print_grammars(). Así además print_grammars() queda como una función más flexible (se le podrían sumar otros parámetros).

También creo que entendí lo de file_name. Eso me permite ahorrarme el bloque dentro de la definición de la clase:

if file_name == None:
            file_name = "lexicon.xml"
        else:
            file_name = file_name

Que la verdad no tenía mucho sentido porque los valores por default se definen mejor como vos decís.

¿Te referías a esto? Si no, hacemos la videollamada y lo terminamos de resolver.

Gracias!

Hola, Facundo. Disculpame la demora en la repsuesta. La notificación quedó sepultada entre otros correos y no la había visto. Efectiamente e refería a esa porción de código. Al indicarla por defecto y/o pasarla siempre desde la función que llama a la clase, te evitás el condicional.

Tanto derivation como parser tiene una clase llamada Derivation. Deberías llamarlas de manera distinta para saber cuál estás incluyendo en el __all__.
PS: O, más bien, de ser posible, podrías modificar la clase Derivation original y agregarle la funcionalidad que desarrollaste.

Mi idea acá era extender la clase Derivation en el módulo parser, para no tocar el archivo original (cosa que igual terminé haciendo). Por eso al "redefinirla", ponía: class Derivation(derivation.Derivation):. Pero puede que la haya duplicado sin querer, la verdad es que no encontré información muy clara sobre esto. Gracias

Claro. Acá hay varias cosas. Voy por partes y lo podemos ir charlando de todas formas:

1. ¿Por qué no querías tocar el archivo original? Si vos estás de acuerdo con que exista una clase llamada Derivation y que esa clase tenga determinados métodos y atributos, lo lógico sería que, al ir desarrollando nueva funcionalidad (lo que vos hiciste), vayas expandiendo los métodos de esa clase, pero no duplicándola.
2. Al definir una nueva clase Derivation que hereda de la primera clase, estás generando una nueva clase que tiene todos los atributos de la primera más los que vos sumaste. En tanto estás usando el mismo nombre es casi como si la redefinieras. Pero no es exactamente eso. O sea, si yo importo la clase Derivation de derivation.py voy a tener la clase original sin ampliar. Si la importo desde parser.py voy a tener la clase ampliada. La pregunta es ¿por qué no tener una única clase que tenga todo? Y, si te fuera de interés que el usuario pueda distinguir entre la clase amppliada y la original, consideraría cambiarle el nombre. De todos modos, recordá que las definiciones de clases también tienen que tener cierto sentido lógico desde la atribución de responsabilidades. Si tenés dudas de esto, decime. Por ahí podemos charlar 15 minutos y queda más claro.
3. Si bien sería un poco raro, podría ser que tengas dos clases llamadas Derivation en archivos distintos de tu código. El problema acá es que vos estás importando todo lo que hay en el archivo parser.py y todo lo que hay en el archivo derivation.py. Y después, en __all__ le indicás que seleccione Derivation: ¿a qué clase Derivation te referís? ¿a la que está en el primero o en el segundo archivo?

Consideraría cambiar esta línea al principio del archivo. Creo que en el código original también hay algún import dentro de funciones, pero en general los imports se organizan al principio del archivo, salvo excepciones como que tengas un flujo de __main__.

Consideraría mover este import al inicio del archivo.