Nltk: Parámetro de función mal escrito para MosesTokenizer: agressive_dash_splits

Gracias @somnathrakshit por las relaciones públicas rápidas. Tenga en cuenta que alterar el nombre del parámetro rompe la API, por lo que podría ser mejor proporcionarlo primero como una opción con una DeprecationWarning cuando se usa el nombre del parámetro anterior, luego se puede eliminar por completo en la próxima versión principal. Tal vez un desarrollador habitual de NLTK pueda comentar sobre el procedimiento aquí, ya que no vi que se mencionara explícitamente en las pautas para desarrolladores o en el documento CONTRIBUTING.md. @alvations , ¿existen pautas o precedentes para cambiar los nombres de funciones / parámetros?

@goodmami @somnathrakshit no se preocupe por romper la API en este caso. La mayoría de la gente estaría más bloqueada por el argumento de error tipográfico en lugar del correcto =)

Con respecto a la obsolescencia y la ruptura del espacio de usuario, en este caso es culpa nuestra y es más fácil para los usuarios actualizar a la nueva versión NLTK.

Pero en otros casos, esp. cuando se trata de cambios más importantes que no son solo errores tipográficos, podemos usar warnings como lo hicimos con las herramientas de Stanford obsoletas https://github.com/nltk/nltk/blob/develop/nltk/tag /stanford.py#L51

Gracias @alvations por hacérnoslo saber. Como principiante en código abierto, ha sido agradable jugar con nltk. ¿Participas en GSoC 2018?

Resuelto en # 1956

@somnathrakshit ¡ Gracias por la contribución! Lamentablemente, no participaremos en GSoC 2018. Quizás otro año en el que tengamos más voluntarios =)