Apostando nisso por enquanto, já que a Woodwork está finalizando os planos para grandes atualizações. Se o Woodwork se tornar uma extensão dos pandas, podemos não querer ou precisar fazer isso.

@angela97lin e eu fizemos check-in e discutimos algumas opções de implementação:

1. Faça com que a avaliação do gráfico de componentes passe pandas para cada componente. Para indicar tipos ww para componentes, adicione novos campos a fit etc., ou mantenha o padrão de recurso de texto de usar parâmetros init para indicar colunas relevantes. Desvantagem: feio do ponto de vista da API, é por isso que criamos o woodwork em primeiro lugar.
2. Durante a avaliação do gráfico de componentes, passe o trabalho em madeira para cada componente. Faça com que cada componente retorne pandas. Desvantagem: uma limitação potencial é que os componentes não podem alterar o tipo de carpintaria dos recursos de entrada ou dos recursos recém-gerados, exceto alterando o tipo de pandas. No entanto, não temos nenhum componente que dependa disso.
3. Durante a avaliação do gráfico de componentes, passe o trabalho em madeira para cada componente. Faça com que cada componente devolva a madeira. Desafio: a maioria dos componentes deve ser convertida em pandas internamente para fazer transformações como adicionar recursos, excluir recursos ou modificar recursos. Após essas transformações, temos que garantir que os tipos de carpintaria originais entrem na nova tabela de dados de carpintaria retornada, caso contrário, as configurações substituídas pelo usuário serão perdidas, como são hoje.

Status: @angela97lin está atualmente buscando a opção 3 em #1668

Plano: continuaremos essa estratégia, atentos ao tempo de execução reduzido devido a várias instanciações de datatable ww. E vamos considerar se há alguma solicitação de recurso que devemos fazer para tornar isso mais fácil. Também ficaremos atentos a quaisquer opções atraentes que possamos ter perdido até agora.

@chukarsten @gsheni

Parece que a terceira opção é a melhor e mais limpa. Espero que o desempenho não seja afetado, mas conceitualmente parece bom. Obrigado por chamar minha atenção... tentando entender todas as coisas.

Hackeando isso e pensando um pouco mais:

O objetivo final é que precisamos de alguma maneira de acompanhar os tipos lógicos originais que o usuário deseja. Essas informações podem ser mantidas pelo gráfico do componente ou transmitidas para cada componente responsável por definir esses tipos de volta após a transformação de alguns dados. Atualmente buscando 3, e adicionando as informações ao gráfico do componente, pois é o mais fácil de testar (em vez de atualizar todos os componentes) ... mas no nível do componente, não faria sentido.

Digamos que um usuário especifique um Woodwork DataTable e converta explicitamente uma coluna categórica em linguagem natural. O usuário passa isso para um componente. Precisamos converter em pandas para passar para bibliotecas externas e gostaríamos de retornar um objeto Woodwork. Se simplesmente chamarmos um construtor Woodwork, ele levaria apenas o tipo inferido (categórico), o que é estranho? Portanto, devemos acompanhar o tipo de linguagem natural especificado original e converter antes de devolver ao usuário.

Interessante notar é o scaler padrão: ele pode pegar colunas int e convertê-las em floats. Se então tentarmos definir o col de volta para o tipo original (int), seremos xingados por tentar converter floats em int quando isso não for seguro. 😬

Atualização: tivemos uma rápida discussão com @dsherry e @chukarsten. No momento, estou implementando o nº 3, mas fazendo com que o gráfico do componente controle os tipos de usuário originais e atualize essas informações à medida que são passadas de componente para componente. Isso funciona bem e nos leva a um local onde o AutoML / pipelines funciona, mas depois que o #1668 for mesclado, devemos lidar com isso no nível do componente e remover esse código do gráfico do componente.

Minhas próximas tarefas: corrigir testes de índice da atualização do branch do main, limpar comentários e problemas de arquivo que podem ser resolvidos não relacionados a este PR (apenas código de limpeza geral). Quando o código estiver mais limpo, procure redundâncias e perfil para ver de onde vem essa enorme diferença de horário / o que podemos fazer a respeito.