Scikit-learn: Sugestão: remova a previsão de plot_confusion_matrix e apenas passe os rótulos previstos

Devemos, definitivamente, permanecer compatíveis com as versões anteriores, mas adicionar um argumento de palavra-chave y_pred parece razoável para mim. Devemos levantar um erro se y_pred for passado, mas X ou estimador também.

Você gostaria de enviar um PR @jhennrich ?

Enviei um PR, mas acho que há um problema com o IC, então ainda não foi aprovado.

Concordo que devemos apoiar plot_XXX(y_true, y_pred) para evitar o cálculo da previsão várias vezes.
Também temos problemas semelhantes em plot_roc_curve e plot_precision_recall_curve.
Adicionar y_pred parece aceitável, mas, honestamente, não acho que seja uma boa solução.
Para as funções que aceitam ** kwargs (por exemplo, plot_precision_recall_curve), parece impossível manter a compatibilidade com versões anteriores?

Por que é impossível manter a compatibilidade com versões anteriores? Parece-me que a proposta em # 15883 está OK

Por que é impossível manter a compatibilidade com versões anteriores? Parece-me que a proposta em # 15883 está OK

porque não oferecemos suporte a ** kwargs em plot_confusion_matrix. @NicolasHug

Por que o kwargs é um problema?

Hmm, então há outra coisa chata, nós suportamos ** kwargs em plot_roc_curve e plot_precision_recall_curve (e plot_partial_dependence), mas não oferecemos suporte em plot_confusion_matrix

Por que o kwargs é um problema?

se adicionarmos o novo parâmetro antes de ** kwargs, podemos manter a compatibilidade com versões anteriores, certo?

As mudanças em meu PR são compatíveis com versões anteriores e ** kwargs ainda podem ser adicionados. Mas eu concordo com @ qinhanmin2014 , uma solução muito mais limpa seria descartar estimator e X e usar argumentos posicionais (y_true, y_pred, ...) que sejam consistentes com a maioria dos outras coisas do sklearn.

se adicionarmos o novo parâmetro antes de ** kwargs, podemos manter a compatibilidade com versões anteriores, certo?

sim

uma solução muito mais limpa ....

Infelizmente, isso exigiria um ciclo de depreciação (a menos que o tornemos muito rápido na versão de correção de bug, mas eu duvido ...)

@thomasjpfan , há algum motivo para passar o estimador como entrada em vez das previsões?

Obrigado, vamos adicionar y_pred primeiro, ** kwags é outro problema.

Infelizmente, isso exigiria um ciclo de depreciação (a menos que o tornemos muito rápido na versão de correção de bug, mas eu duvido ...)

Isso parece impossível, suspiro

@thomasjpfan , há algum motivo para passar o estimador como entrada em vez das previsões?

Concordo que precisamos reconsiderar nosso design de API. também tente pingar @amueller

Se um usuário deseja fornecer sua própria parte de plotagem e fornecer sua própria matriz de confusão:

from sklearn.metrics import ConfusionMatrixDisplay
confusion_matrix = confusion_matrix(...)
display_labels = [...]

disp = ConfusionMatrixDisplay(confusion_matrix=confusion_matrix,
                              display_labels=display_labels)
disp.plot(...)

Isso pode ser feito de forma semelhante para as outras funções de plotagem de métricas.

O plot_confusion_matrix é meio que desenhado como os marcadores que são capazes de lidar bem com a saída dos estimadores. Em outras palavras, é um invólucro conveniente para interagir com ConfusionMatrixDisplay e o estimador.

Ao aceitar o estimador primeiro, há uma interface uniforme para as funções de plotagem. Por exemplo, plot_partial_dependence faz todos os cálculos necessários para criar os gráficos de dependência parcial e os passa para PartialDependenceDisplay . Um usuário ainda pode criar PartialDependenceDisplay própria, mas nesse caso seria mais complicado.

No entanto, estou aberto a ter um "caminho rápido", permitindo que y_pred seja passado para as funções de plotagem relacionadas às métricas, que serão passadas diretamente para confusion_matrix e deixarão lidar com a validação.

O cálculo das previsões necessárias para construir PDPs é bastante complexo. Além disso, essas previsões são normalmente inutilizáveis, por exemplo, em um marcador ou métrica. Eles são úteis apenas para traçar o PDP. Portanto, faz sentido, neste caso, aceitar apenas o estimador em plot_partial_dependence.

OTOH para a matriz de confusão, as previsões são realmente apenas est.predict(X) .

Não acho que queremos uma interface uniforme aqui. Estes são 2 casos de uso de entrada muito diferentes

EDIT: Além disso, os PDPs baseados em árvore nem mesmo precisam de previsões

Existem outras coisas que encontraremos sem o estimador. Por exemplo, se plot_precision_recall_curve aceitar y_pred , será necessário pos_label porque não pode mais ser inferido. Nesse caso, eu preferiria usar PrecisionRecallDisplay diretamente e fazer com que o usuário calculasse os parâmetros necessários para reconstruir o gráfico.

Isso se resume a que tipo de pergunta estamos respondendo com esta API. A interface atual gira em torno da avaliação de um estimador, usando, portanto, o estimador como argumento. Ele é motivado por responder "como este modelo treinado se comporta com esses dados de entrada?"

Se aceitarmos y_pred, y_true , agora a pergunta se torna "como essa métrica se comporta com esses dados?" Esses dados podem ou não ser gerados por um modelo.

É verdade que, neste caso específico, @jhennrich você pode estar usando diretamente o ConfusionMatrixDisplay.

Uma desvantagem é que você precisa especificar display_labels pois não há padrão.

@thomasjpfan , você acha que poderíamos, em geral, fornecer padrões razoáveis ​​para os objetos de exibição, tornando assim o uso direto dos objetos de exibição prático?

Para alguns parâmetros, como display_labels , existe um padrão razoável. Os outros Display parâmetros de objeto também podem ter padrões razoáveis. Alguns parâmetros devem ser fornecidos. Por exemplo, confusion_matrix deve ser fornecido para ConfusionMatrixDisplay ou precision e recall para PrecisionRecallDisplay .

Um padrão clássico para esse tipo de coisa é definir:

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

mas isso não é muito idiomático para o scikit-learn.

Eu começo a ficar confuso. O objetivo da API atual é evitar calcular várias vezes se os usuários quiserem plotar várias vezes, mas se aceitarmos y_true e y_pred, os usuários ainda não precisarão calcular várias vezes? (Eu sei que as coisas são diferentes no PDP)

@jnothman Essa API é muito bonita!

@ qinhanmin2014 Passar estimator, X, y ou y_true, y_pred funciona para satisfazer a API "não calcular várias vezes". Em ambos os casos, a matriz de confusão é calculada e armazenada no objeto Display .

A diferença entre eles é onde começa o cálculo da matriz de confusão. Pode-se pensar em passar y_pred como o valor "pré-calculado" do estimador.

Portanto, acho que y_true, y_pred é melhor do que estimator, X, y (não no PDP, é claro), porque às vezes (frequentemente?) Os usuários não querem apenas traçar as previsões, mas também analisá-las. Com a API atual, eles precisarão calcular as previsões várias vezes.

Para métricas, posso ver a preferência em usar y_true, y_pred vez de estimator, X, y . Imagine se a plotagem de métricas suportasse apenas y_true, y_pred

est = # fit estimator

plot_partial_dependence(est, X, ...)

# if plot_confusion_matrix accepts `y_true, y_pred`
y_pred = est.predict(X)
plot_confusion_matrix(y_true, y_pred, ...)

# if plot_roc_curve supports `y_true, y_score`
y_score = est.predict_proba(X)[: , 1]
plot_roc_curve(y_true, y_score, ...)
plot_precision_recall_curve(y_true, y_score, ...)

Atualmente, a API se parece com:

est = # fit estimator
plot_partial_dependence(est, X, ...)
plot_confusion_matrix(est, X, y, ...)
plot_roc_curve(est, X, y, ...)

# this will call `predict_proba` again
plot_precision_recall_curve(est, X, y, ...)

Eu preferiria ter uma API que suporte ambas as opções (de alguma forma).

Para métricas, posso ver a preferência em usar y_true, y_pred em vez de estimador, X, y. Imagine se a plotagem de métricas suportasse apenas y_true, y_pred

Sim, é isso que quero dizer.

Eu preferiria ter uma API que suporte ambas as opções (de alguma forma).

Acho que essa é uma solução prática. Uma coisa irritante é que só podemos adicionar y_pred no final (ou seja, plot_confusion_matrix (estimador, X, y_true, ..., y_pred))

Sim, será no final e a API ficaria assim:

plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

com o qual eu acho que estou bem. Este é essencialmente o PR https://github.com/scikit-learn/scikit-learn/pull/15883

Sim, será no final e a API seria semelhante a plot_confusion_matrix (y_true = y_true, y_pred = y_pred, ...)

Eu acho que você quer dizer que devemos adicionar y_true e remover est & X, certo? Eu acho que é impossível? (porque só podemos adicionar y_pred no final)

Queremos resolver isso em 0.22.1? @NicolasHug @thomasjfox Acho que vale a pena colocar isso no 0.22.1, mas ao mesmo tempo, parece que é um recurso novo.

Não, não coloque em 0.22.1. é uma violação clara do semver

@ qinhanmin2014 Adicionar y_pred no final ou remover est, X parece ser um novo recurso que pertence ao próximo lançamento.

Eu acho que você quer dizer que devemos adicionar y_true e remover est & X, certo? Eu acho que é impossível?

No final, eu preferiria ter suporte para ambas as interfaces, porque elas têm casos de uso ligeiramente diferentes.

1. est, X é mais fácil de fazer uma análise rápida, porque a função trata da escolha da função de resposta, fatiando o resultado e passando-o para a métrica.
2. y_true, y_pred é para usuários que entendem como trabalhar com a métrica subjacente e têm as previsões já salvas.

Qual é o problema em fazer https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619?

Eu não li todo este tópico, mas se permitirmos a interface aqui, também precisamos fazer isso para plot_roc_curve onde a interface será bastante diferente entre fornecer previsões e fornecer o estimador (um precisa de pos_label e o outro não 't).
Então eu acho que permitir ambos na mesma interface é uma má ideia (alguém vai passar pos_label ao passar um estimador e obter um resultado que não esperava).

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

Poderia funcionar, mas basicamente tornaria plot_confusion_matrix redundante, então removeríamos as funções novamente e mudaríamos as responsabilidades entre a classe e a função (dissemos que a classe não faz o cálculo).

Se quisermos adicionar from_predictions a plot_roc_curve ele precisa basicamente espelhar a interface roc_curve perfeitamente. Portanto, não acho que seja tão ruim que o usuário chame a função roc_curve diretamente e, em seguida, passe os resultados para o objeto Display.

Todo o propósito do design dos objetos de exibição era permitir o caso de uso mencionado por @jhennrich e por que separamos o cálculo da função. Eu não vi um argumento sobre por que devemos recuar nessa decisão ainda.

@amueller Tecnicamente, você está certo, a solução atual para o meu problema é apenas usar ConfusionMatrixDisplay . No entanto, é muito difícil de usar:

• você tem que passar os rótulos explicitamente
• você tem que calcular a matriz de confusão primeiro
• você tem que criar um objeto da classe e ainda chamar o método plot

Para todos os aplicativos que posso pensar em uma assinatura plot_confusion_matrix com (y_true, y_pred, ...) seria muito mais conveniente do que o que temos atualmente. Em minha opinião, há muito mais casos de uso em que você deseja calcular explicitamente as previsões (embora eu tenha certeza de que minha visão é tendenciosa).

Se você tiver uma assinatura plot_confusion_matrix(y_true, y_pred) e realmente quiser usá-la nos dados de estimator , x , y , há muito pouco código adicional para escrever : plot_confusion_matrix(y, estimator.predict(x)) .
Em comparação, se você tem a assinatura atual e deseja traçar de y_true e y_pred , você precisa escrever muito mais código.

Na minha opinião, a assinatura plot_confusion_matrix(y_true, y_pred) deve ser padrão e outra função que usa estimator , x , y deve ser construída no topo.

Por último, mas não menos importante, eu honestamente não entendo a ideia por trás da classe ConfusionMatrixDisplay . A função tem apenas um único construtor e exatamente um método, então sempre que você usá-la, você acaba criando uma instância e chamando a função plot . Não vejo por que isso deve ser uma aula e não apenas uma função. Também existem outras classes *Display (PrecisionRecall, ROC, ...), mas suas assinaturas de construtor e plot() são completamente diferentes, portanto, não podem ser trocadas de qualquer maneira.
Talvez isso vá além do escopo deste problema.

@jhennrich

Se você tiver uma assinatura plot_confusion_matrix (y_true, y_pred) e realmente quiser usá-la nos dados do estimator, x, y, há muito pouco código adicional para escrever: plot_confusion_matrix (y, estimator.predict (x)).

Para o caso da matriz de confusão, é simples passar estimator.predict se tivéssemos uma interface y_true, y_pred . Por outro lado, para plot_roc_auc , o usuário precisaria fazer o fatiamento:

y_pred = est.predict_proba(X)
plot_roc_curve(y_true, y_pred[:, 1])

# or
y_pred = est.decision_function(X)
plot_roc_curve(y_true, y_pred[:, 1])

Por último, mas não menos importante, eu honestamente não entendo a ideia por trás da classe ConfusionMatrixDisplay. A função possui apenas um único construtor e exatamente um método, portanto, sempre que você a usa, acaba criando uma instância e chamando a função plot. Não vejo por que isso deve ser uma aula e não apenas uma função.

O propósito dos objetos Display é armazenar os valores computados permitindo que os usuários chamem plot muitas vezes sem recomputar. Isso pode ser visto usando plot_partial_dependence :

# Does expensive computation
disp = plot_partial_dependence(est, ...)

# change line color without needing to recompute partial dependence
disp.plot(line_kw={"c": "red"})

Honestamente, estou em dúvida quanto a essa questão. Estou com +0,1 para mover para copiar a interface de métricas para plotagem de métricas e remover a interface est, X, y . : /

Para o caso da matriz de confusão, é simples passar estimator.predict se tivéssemos uma interface y_true, y_pred. Por outro lado, para plot_roc_auc, o usuário precisaria fazer o fatiamento:

Sim, mas ao fazer isso, evitamos calcular a previsão várias vezes (embora a previsão muitas vezes não seja tão cara)

Talvez uma solução prática seja apoiar y_true, y_pred em plot_XXX (quando aplicável) em 0,23.

@jhennrich Como você fará isso sem passar os rótulos explicitamente? Se os rótulos puderem ser inferidos do que é fornecido, confusion_matrix fará isso por você.

Mas, de fato, você está certo, são três linhas em vez de uma.

No caso de confused_matrix, tendo a concordar que o caso mais comum pode ser passar y_true e y_pred .
A razão pela qual a interface atualmente é do jeito que está é para ser consistente com as outras funções de plotagem de métricas. Como @thomasjpfan disse, a curva roc é menos óbvia de traçar.

No momento, o código para traçar uma matriz de confusão e traçar uma curva roc são os mesmos. Com a mudança sugerida, eles não serão mais os mesmos e não haverá uma maneira fácil de torná-los iguais.

A questão é se neste caso é melhor ter interfaces consistentes ou ter uma interface simples.
@jhennrich Para mim, a verdadeira questão é qual é a interface certa para plot_roc_curve . Você tem alguma opinião sobre isso?

@thomasjpfan , você y_store para traçar roc auc também?

Certamente, há prós e contras em usar a interface do marcador em vez de usar a interface métrica. Mas para coisas mais complexas, é muito mais seguro usar a interface do marcador.

@ qinhanmin2014
Acho que seria bom adicionar y_pred a plot_confusion_matrix . A questão é se queremos adicionar y_score a plot_roc_curve e plot_precision_recall_curve . Se fizermos isso, também teremos que adicionar pos_label como eu disse acima, e as coisas ficarão mais complicadas.

Eu vejo três maneiras de sair disso:
a) Apenas adicione y_pred a plot_confusion_matrix , mas não adicione y_score a plot_roc_curve etc. Desvantagem: o problema de chamar predict_proba várias vezes continua existindo para essas métricas.
b) Torne mais fácil usar o objeto Display diretamente (embora eu realmente não saiba como).
c) Adicione outro método ou função que espelhe a interface métrica. Desvantagem: maior superfície de API.

Não acho que ter a função plot_X espelhando o marcador e a interface métrica ao mesmo tempo seja uma boa ideia em geral.

Eu acho que seria ótimo resolver isso de alguma forma @adrinjalali você gostaria de discutir isso na próxima reunião talvez?

Às vezes tenho pesadelos com esse problema. Talvez possamos adicionar um método estático que obtém a saída da métrica diretamente:

result = confusion_matrix(...)
ConfusionMatrixDisplay.from_metric(result).plot()

Para curva roc:

result = roc_curve(...)
RocCurveDisplay.from_metric(*result).plot()

Observando as bases de código, acho que mais usuários estão familiarizados com a interface de métricas do que com a interface de pontuação.

Às vezes tenho pesadelos com esse problema.

Oh não :(

Observando as bases de código, acho que mais usuários estão familiarizados com a interface de métricas do que com a interface de pontuação.

Acho que isso é definitivamente verdade. Mas também estou certo de que as pessoas usam y_pred quando deveriam estar usando y_score e estão obtendo resultados errados porque a interface não diz que você precisa fazer algo diferente e não sempre se lê a documentação.

Não tenho certeza de como o método estático que você propõe é diferente do construtor, mas talvez eu esteja negligenciando algo.

Olá, acabei de votar a questão - como um usuário de longa data do sklearn, achei a API atual para plot_confusion_matrix muito ... bem, confusa. Eu realmente gosto de sua adição (menos copiar e colar), mas as funções de métricas sempre usaram o esquema (y_true, y_pred) que é apenas mais flexível e o que eu já estou acostumado.

No meu caso, não faz sentido passar um estimador, pois é um modelo muito lento e prefiro carregar as previsões de um arquivo do que executá-lo novamente sempre que quiser analisar os resultados. Estou feliz por ter descoberto neste tópico que há uma solução alternativa para usar o objeto * Display, mas sua descoberta não é ótima - eu sugeriria pelo menos adicionar isso à documentação plot_confusion_matrix ou talvez ao guia do usuário da matriz de confusão ?

No meu caso, não faz sentido passar um estimador, pois é um modelo muito lento e prefiro carregar as previsões

Obrigado pela sua contribuição. Se a API atual é confusa, faria cada vez mais sentido mudar para uma interface mais parecida com a API de métricas e passar por um doloroso ciclo de reprovação.

A maior preocupação que temos com o uso da interface de métricas é:

Mas também estou certo de que as pessoas usam y_pred quando deveriam estar usando y_score e estão obtendo resultados errados porque a interface não diz que você precisa fazer algo diferente e ninguém nunca lê os documentos.

@pzelasko Qual é sua opinião sobre este assunto?

@thomasjpfan Eu entendo o problema, é difícil. Talvez um compromisso razoável seria permitir apenas argumentos de palavra-chave para esta função (agora que você não precisa mais suportar Python 2)? Como: def plot_confusion_matrix(*, y_true, y_pred, ...) . Ainda é diferente do resto das métricas, mas 1) tem um bom motivo para isso, 2) está usando pelo menos o mesmo tipo de entrada que as outras funções.

De qualquer forma, eu sei por que você está hesitante em fazer qualquer alteração na API, é por isso que sugeri pelo menos mencionar a solução alternativa nos documentos. (Na verdade, eu os li várias vezes e realmente os aprecio!)

A forma atual de usar y_true e y_pred é mostrada aqui: https://scikit-learn.org/stable/auto_examples/misc Miscellaneous/plot_display_object_visualization.html y_pred create -confusionmatrixdisplay

Eu sei que estou me alongando aqui, mas e quanto a isso:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ...)

onde a segunda posição aceita y_true como previsões se estimator='precomputed .

se você quiser esticar ainda mais, eu preferiria plot_confusion_matrix((estimator, X, y), ...) ou plot_confusion_matrix((y_true, y_pred), ...) mas não tenho certeza se isso está resolvendo os problemas levantados por @amueller em relação à API do tipo métrica

Existem alguns novos utilitários de plotagem onde permitir uma API metric faria realmente sentido:

• plot_prediction_error em https://github.com/scikit-learn/scikit-learn/pull/18020
• plot_calibration_curve em https://github.com/scikit-learn/scikit-learn/pull/17443 (CC @lucyleeow )

Eu entendo o problema que @amueller mencionou sobre a necessidade de passar pos_label etc., mas isso não é um problema para nenhuma das funções mencionadas acima.

Podemos oferecer suporte ao indicador e à API de métricas para esses dois? Não precisamos nos preocupar com a compatibilidade com versões anteriores.

Ainda estou a favor da minha sugestão de usar precomputed , que normalmente usamos em nossos estimadores. Nesse caso, a assinatura seria:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ..., metric_kwargs=None)

Vou montar RP para ver como é.

Na verdade, não estou discutindo a API ainda, estou apenas perguntando se estamos OK para oferecer suporte a ambas as opções para novos PRs.

(Mas em relação à API, não acho que 'pré-computado' ajude muito: o que fazemos com X ? Acho que devemos apenas manter (y_pred) e (estimador, X) mutuamente exclusivos, errando apropriadamente . Além disso, o que significa para um estimador ser pré-computado?)

Ou estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , e então X torna-se y_pred ou y_score . É quase como lidar com distâncias pré-computadas com X em estimadores.

Podemos oferecer suporte ao indicador e à API de métricas para esses dois?

Como vamos oferecer suporte a ambas as opções? Com duas funções?

Eu também teria gostado de:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

que seriam dois métodos.

A sugestão de Guillaume de usar tuplas https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 é uma opção. Acho que teria sido a melhor opção se tivéssemos começado desde o início. Mas temo que usar tuplas quebre a consistência com os utilitários existentes.

plot_XYZ(estimator=None, X=None, y=None, y_pred=None) com exclusão mútua é outra opção, e é a que estou defendendo, por enquanto.

Eu gosto de CalibrationDisplay.from_estimator(...) , mas como Andy observou, precisaríamos remover as funções plot_XYZ então. Pode valer a pena considerar.

Acho que podemos mudar para tuplas e descontinuar o comportamento atual. (Contanto que concordemos em usar tuplas)

Parece que estamos discutindo os namespaces, certo?
Quer tenhamos uma função e um construtor, ou dois métodos de classe, ou duas funções, é exatamente a mesma funcionalidade e basicamente o mesmo código.

@pzelasko @jhennrich, como você se sente por ter dois métodos de classe ou duas funções? Ou você prefere uma única função, que é um pouco confusa em python.

E se você preferir duas funções ou dois métodos de classe, você vê algum benefício, apesar da descoberta? A capacidade de descoberta pode ser uma razão suficiente para fazer métodos de classe, porém, não vejo um argumento forte para ter duas funções.

Podemos adicionar o rótulo do bloqueador aqui? Parece que está impedindo o progresso em # 18020 e # 17443 (cc @cmarmo)

O rótulo do bloqueador é para bloqueadores de lançamento (coisas que absolutamente precisam ser corrigidas antes de um lançamento), não para bloqueadores de PR

Ahh bom saber.

@pzelasko @jhennrich, como você se sente por ter dois métodos de classe ou duas funções? Ou você prefere uma única função, que é um pouco confusa em python.

E se você preferir duas funções ou dois métodos de classe, você vê algum benefício, apesar da descoberta? A capacidade de descoberta pode ser uma razão suficiente para fazer métodos de classe, porém, não vejo um argumento forte para ter duas funções.

Eu gosto mais da abordagem dos métodos de duas classes, especialmente do padrão from_xxx - algo como @thomasjpfan proposto:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

Parece que não há forte oposição ao uso de 2 métodos de classe, então vamos fazer isso. Precisamos:

• Apresente os métodos de classe para os gráficos existentes atualmente:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . Para este, não queremos introduzir o método from_predictions class porque não faria sentido, queremos apenas from_estimator .

• Para todos os Display listados acima, desative sua função plot_... . Não precisamos descontinuar plot_det_curve porque ele ainda não foi lançado, podemos apenas removê-lo.

• para novos PRs como # 17443 e # 18020, podemos implementar os métodos de classe imediatamente em vez de introduzir uma função plot .

Isso é um pouco trabalhoso, mas acho que podemos fazer isso antes de 0,24 para que os números 17443 e 18020 já possam avançar.

Alguma objeção @thomasjpfan @jnothman @amueller @glemaitre ?

@jhennrich @pzelasko , você estaria interessado em enviar um PR para apresentar os métodos de classe em um dos objetos Display?

Obrigado por tomar a decisão @NicolasHug! Vou entrar no # 17443 (depois de esperar por objeções)

Não tenho objeções.

Nenhuma objeção também.

Eu cuidarei das outras classes então e avançarei meu PR estagnado.
@lucyleeow , caso eu não tenha feito tudo isso e você esteja procurando alguns PRs, envie um ping :)

Adoraria contribuir, mas estou envolvido em muitos projetos no momento. Obrigado por ouvir as sugestões!

Soa bem :)