Descartando esto por ahora, dado que Woodwork está finalizando los planes de grandes actualizaciones. Si Woodwork se convierte en una extensión de pandas, es posible que no queramos o necesitemos hacer esto.

@angela97lin y yo nos registramos y discutimos algunas opciones de implementación:

1. Haga que la evaluación del gráfico de componentes pase pandas a cada componente. Para indicar los tipos de ww a los componentes, agregue nuevos campos a fit , etc., o siga el patrón de características de texto de usar parámetros de inicio para indicar las columnas relevantes. Desventaja: desagradable desde la perspectiva de la API, es por eso que creamos la carpintería en primer lugar.
2. Durante la evaluación del gráfico de componentes, pase la carpintería a cada componente. Haga que cada componente devuelva pandas. Desventaja: una posible limitación es que los componentes no pueden cambiar el tipo de carpintería de las entidades de entrada o de las entidades recién generadas, excepto cambiando el tipo de pandas. Sin embargo, no tenemos ningún componente que dependa de esto.
3. Durante la evaluación del gráfico de componentes, pase la carpintería a cada componente. Haga que cada componente devuelva la carpintería. Desafío: la mayoría de los componentes deben convertirse a pandas internamente para realizar transformaciones como agregar características, eliminar características o modificar características. Después de esas transformaciones, debemos asegurarnos de que los tipos de carpintería originales entren en la nueva tabla de datos de carpintería devuelta; de lo contrario, la configuración anulada por el usuario se perderá, como ocurre hoy.

Estado: @angela97lin actualmente busca la opción 3 en el n.º 1668

Plan: continuaremos con esa estrategia, estando atentos a la reducción del tiempo de ejecución debido a las múltiples instancias de la tabla de datos ww. Y consideraremos si hay alguna solicitud de función que debamos hacer a la carpintería para que sea más fácil. También estaremos atentos a cualquier opción atractiva que nos hayamos perdido hasta ahora.

@chukarsten @gsheni

Parece que la tercera opción es la mejor y más limpia. Esperemos que el rendimiento no se vea afectado, pero conceptualmente parece sólido. Gracias por traerlo a mi atención... tratando de entender todas las cosas.

Hackeando esto y pensando un poco más:

El objetivo final es que necesitamos alguna forma de realizar un seguimiento de los tipos lógicos originales que desea el usuario. Esta podría ser información retenida por el gráfico de componentes, o transmitida a cada componente que es responsable de restablecer esos tipos después de transformar algunos datos. Actualmente buscando 3, y agregando la información al gráfico de componentes, ya que es lo más fácil de probar (en lugar de actualizar cada componente)... pero a nivel de componente, no tendría sentido.

Supongamos que un usuario especifica un Woodwork DataTable y convierte explícitamente una columna categórica en lenguaje natural. El usuario pasa eso a un componente. Necesitamos convertir a pandas para pasar a bibliotecas externas, y nos gustaría devolver un objeto Woodwork. Si simplemente llamamos a un constructor de Woodwork, solo tomaría el tipo inferido (categórico), ¿cuál es impar? Por lo tanto, debemos realizar un seguimiento del tipo de lenguaje natural especificado original y convertirlo antes de devolvérselo al usuario.

Es interesante tener en cuenta el escalador estándar: podría tomar columnas int y convertirlas en flotantes. Si luego tratamos de establecer la col de nuevo en el tipo original (int), nos gritarán por tratar de convertir flotantes a int cuando eso no es seguro. 😬

Actualización: tuve una discusión rápida con @dsherry y @chukarsten. Actualmente estoy implementando el n. ° 3, pero el gráfico de componentes se encarga de realizar un seguimiento de los tipos de usuarios originales y actualizar esa información a medida que pasa de un componente a otro. Esto funciona bien y nos lleva a un lugar donde AutoML / canalizaciones funcionan, pero después de fusionar # 1668, debemos abordar el manejo de esto en el nivel de componente y eliminar este código del gráfico de componente.

Mis próximas tareas pendientes: corregir las pruebas de índice de la rama de actualización desde la principal, limpiar los comentarios y los problemas de archivos que pueden abordarse y no están relacionados con este PR (solo código de limpieza general). Una vez que el código esté más limpio, busque las redundancias y el perfil para ver de dónde proviene esta enorme diferencia horaria y qué podemos hacer al respecto.