Gracias por abrir este número, ping @jnothman @amueller @GaelVaroquaux según gitter

8425 no está relacionado con las regiones de decisión de los clasificadores ,?

Prefiero mover plot_tree y plot_partial_dependence a sklearn.plot y resolver # 13335 en 0.21 (tal vez introducir una función para trazar el límite de decisión, ya que es importante y no es fácil para principiantes en mi opinión). ¿Qué piensan los demás?

Para ayudar a controlar el alcance de sklearn.plot, propongo que solo tracemos en el nivel de los ejes y no en el nivel de la figura. El usuario pasaría los ejes como palabra clave. Para su comodidad, el valor predeterminado de los ejes será Ninguno. Solo en este caso, la función de trazado generará un eje / figura para trazar.

Buena idea, pero no coherente con las funciones existentes (plot_tree y plot_partial_dependence), ¿verdad?

Hay casos en los que necesita generar / modificar una figura, como con
múltiples subtramas (ver las parcelas de facetas de seaborn, etc., y la trama alterada para
ejemplo). ¿Puede dar razones por las que quiere limitarlo a los ejes?

El viernes 15 de marzo de 2019 a las 2:19 am, Hanmin Qin, [email protected] escribió:

Gracias por abrir este número, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux según gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 no es

relacionado con las regiones de decisión de los clasificadores ,?
Prefiero mover plot_tree y plot_partial_dependence a sklearn.plot y
resolver # 13335 https://github.com/scikit-learn/scikit-learn/issues/13335
en 0.21 (tal vez introduzca una función para trazar el límite de decisión, ya que
es importante y no es fácil para los principiantes en mi opinión). ¿Qué piensan los demás?

Para ayudar a controlar el alcance de sklearn.plot, propongo que solo tracemos
en el nivel de los ejes y no en el nivel de la figura. El usuario pasaría en los ejes
como palabra clave. Para su comodidad, el valor predeterminado de los ejes será Ninguno. Solo en
En este caso, la función de trazado generará un eje / figura sobre el que trazar.

Buena idea, pero no coherente con las funciones existentes (plot_tree y
plot_partial_dependence), ¿verdad?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Buena idea, pero no coherente con las funciones existentes (plot_tree y plot_partial_dependence), ¿verdad?

@ qinhanmin2014 plot_tree no parece ajustar la cifra. plot_partial_dependence hace múltiples gráficos basados ​​en features . Aunque, se puede refactorizar en un gráfico de nivel de ejes. Un usuario necesitaría llamar a plot_partial_dependence varias veces dándole diferentes ejes (y características).

¿Puede dar razones por las que quiere limitarlo a los ejes?

@jnothman Seaborn tiene documentación que separa claramente la trama de "nivel de figura" y la trama de "nivel de ejes". Si podemos documentar correctamente este comportamiento en scikit-learn, es posible tener estos diagramas de "nivel de figura". Mi mayor preocupación con los gráficos "a nivel de figura" es que son más difíciles de mantener y probar. Habrá elementos de un eje que pueden superponerse con otros ejes. Sin embargo, podemos solucionar esto estructurando las cifras de tal manera que la superposición ocurra con menos frecuencia.

En términos de pruebas, podemos seguir el camino de Seaborn y probar directamente los objetos matplotlib o la forma de Yellowbrick donde hacemos pruebas a nivel de píxeles. Tiendo a favorecer la prueba de los objetos matplotlib.

Mis 2 centavos:

• +1 para contener las funciones que acceden a matplotlib en un subpaquete común, o en un módulo en cada subpaquete (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Como lo mencionó @thomasjpfan , solo acceder a los ejes facilita la prueba.

  Además, hace mucho tiempo, se discutió en el ecosistema para dar a otros backends de trazado un objeto similar a "Axes" por compatibilidad. No sé a dónde fue eso. Una búsqueda rápida en Google no muestra mucho. El más cercano es plotly.tools.mpl_to_plotly, que realmente no necesita esta restricción, así que creo que ese argumento es en vano.

tal vez introducir una función para trazar el límite de decisión, ya que es importante y no es fácil para los principiantes, en mi opinión

Estoy de acuerdo, pero también creo que mostrar a los usuarios cómo trazar resultados, como límites de decisión, es uno de los objetivos de los ejemplos.

Si quiero un primer gráfico rápido de un resultado, las funciones de trazado son excelentes, especialmente para gráficos complicados como trazar un árbol, pero muy a menudo me gusta ajustar el gráfico a mis necesidades y por esa razón prefiero confiar en ejemplos existentes y modificar el código.

En cuanto al nombre del módulo, IMO inspect es más versátil que plot :

• No puedo pensar en ninguna trama que no sea una especie de inspección.
• # 12599 (Dependencia parcial) ya introduce inspect

La inspección de la OMI es más versátil que la trama

sin una opinión fuerte, votará +1 por ambos nombres. ¿Quizás la trama es más sencilla?

Nuevamente, estoy interesado en crear el nuevo módulo antes de 0.21 y mover plot_tree y plot_partial_dependence allí. Idealmente, también deberíamos llegar a un consenso sobre la API (por ejemplo, nivel de ejes / nivel de figura).

Otro punto a favor de inspect :

Es posible que deseemos inspeccionar herramientas que ofrezcan el trazado como una opción. Por ejemplo, imprima las características de un árbol (número de nodos, hojas, puntos de división, etc.) y, opcionalmente, grábelo con matplotlib.

Yo estaría a favor de usar ejes en lugar de cifras, como se sugirió (suspiro, tendré que cambiar los PDP nuevamente). Es más fácil para nosotros apoyar y probar. Es un poco más de trabajo para los usuarios, pero también permite un mayor control.

La inspección de la OMI es más versátil que la trama

sin una opinión fuerte, votará +1 por ambos nombres. ¿Quizás la trama es más sencilla?

"inspeccionar" se carga en Python (es un módulo en la biblioteca estándar). I
evitaría usar el mismo nombre.

Nuevamente, estoy interesado en crear el nuevo módulo antes de 0.21 y mover plot_tree y plot_partial_dependence allí. Idealmente, también deberíamos llegar a un consenso sobre la API (por ejemplo, nivel de ejes / nivel de figura).

Esto no debería demorar 0.21. Nuestro objetivo es lanzar temprano y, con suerte,
suelte temprano de nuevo.

"inspeccionar" se carga en Python (es un módulo en la biblioteca estándar). I
evitaría usar el mismo nombre.

Propongo model_inspection . Va bien con nuestro nombre model_selection .

Es posible que deseemos inspeccionar algo que no sea un modelo (codificador, preprocesador, resultados de búsqueda de cuadrícula ...)

inspection entonces?

Esas cosas también son modelos :)

La sugerencia de Gael de un submódulo de trama pública en cada subpaquete vale
considerando.

FWIW, también preferiría plot a inspect , ya que es más intuitivo para la mayoría de los usuarios encontrarlo. Es más probable que las personas intenten _plotar_ sus modelos que _inspeccionar_ sus modelos (al buscar en motores de búsqueda, por ejemplo, o al mirar las posibles opciones de autocompletar en su IDE).

Vale la pena considerar la sugerencia de Gael de un submódulo de trama pública en cada subpaquete.

Si es así, ¿dónde pondremos plot_decision_boundary ?

Con respecto a # 12599, @NicolasHug dudo que partial_dependence deba estar en el nuevo módulo. (es decir, ensemble.partial_dependence + plot.plot_partial_dependence)

Si es así, ¿dónde pondremos plot_decision_boundary?

sklearn.plot?

No quiero presionar demasiado por esta solución. Sin embargo, estoy de acuerdo con
la sensación de que la "trama" puede ser más fácil de descubrir para los usuarios finales.

Con respecto al # 12599, @NicolasHug dudo que la

No entiendo lo que quieres decir. # 12599 desaprueba ensemble.partial_dependence a favor de inspect.partial_dependence (por supuesto, inspect está sujeto a cambios según esta discusión). La API también difiere entre las 2 implementaciones.

Estoy bien con plot , solo me preocupa una posible superposición alta con un módulo de inspección eventual, pero no lo presionaré más :)

Vale la pena considerar un submódulo de parcela pública en cada subpaquete.

Pero hasta ahora, todas las herramientas de trazado que se proponen (PDP, calibración, matriz de confusión y región de decisión) no son específicas de un solo módulo.

No entiendo lo que quieres decir. # 12599 desaprueba ensemble.partial_dependence a favor de inspect.partial_dependence (por supuesto, inspeccionar está sujeto a cambios según esta discusión). La API también difiere entre las 2 implementaciones.

Disculpas, no he mirado ese PR en detalle. ¿Quizás inspect.partial_dependence + plot.plot_partial_dependence ?

¿Quizás inspect.partial_dependence + plot.plot_partial_dependence?

Me gusta una separación clara entre calcular los valores y graficarlos.
Es un modelo / vista como la separación, y debería ayudar a aumentar la
reutilización.

¿No estaba Gaël antes proponiendo sklearn.inspect.partial_dependence y
sklearn.inspect.plot.plot_partial_dependence (Sustituya por otro nombre
para inspeccionar si es apropiado)? No me importa esto.

¿No estaba Gaël proponiendo anteriormente sklearn.inspect.partial_dependence y sklearn.inspect.plot.plot_partial_dependence (sustituya inspeccionar por otro nombre si corresponde)?

Sí, pero le pregunté dónde pondríamos plot_decision_boundary y parece que cambió de opinión.

Para su información, actualicé el PDP PR https://github.com/scikit-learn/scikit-learn/pull/12599 siguiendo las recomendaciones anteriores:

• partial_dependence está en sklearn.model_inspection
• plot_partial_dependence está en skearn.plot

Los documentos están aquí https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

Tenga en cuenta que la guía del usuario solo incluye el módulo plot por ahora. No creo que tenga sentido tener una sección de la guía del usuario que solo hable sobre model_inspection.partial_dependence , ya que sus restricciones / comportamiento son los mismos que los de plot_partial_dependence .

(Este es el tipo de superposición que me preocupaba)

Por supuesto, si cree que es mejor tener guías de usuario separadas para partial_dependence y plot_partial_dependence , lo haré.

Para su información, actualicé el PDP PR # 12599 siguiendo las recomendaciones anteriores:
la dependencia_parcial está en sklearn.model_inspection
plot_partial_dependence está en skearn.plot

+1

Tenga en cuenta que la guía del usuario solo incluye el módulo de trazado por ahora. No creo que tenga sentido tener una sección de la guía del usuario que solo hable sobre model_inspection.partial_dependence, ya que sus restricciones / comportamiento es el mismo que el de plot_partial_dependence.

+1

Entonces, ¿hemos decidido usar el nombre sklearn.plot?

Creo que sklearn.plot importar dependencias de sklearn es un poco extraño cuando hemos evitado poner a todos en el espacio de nombres raíz.

Entonces, ¿preferirías sklearn.model_inspection.plot y poner plot_partial_dependence() allí?

Sin módulo plot , estoy bien con eso

Creo que preferiría eso. Todavía no estoy seguro de cómo se generaliza.

Creo que preferiría eso. Todavía no estoy seguro de cómo se generaliza.

Siempre que podamos encontrar un lugar apropiado para poner cosas como plot_decision_boundary , votaré +1 por sklearn.XXX.plot .

¿Esto necesita un descanso? no parece que estemos progresando mucho

EDITAR ugh, me tiene sueño, leí el comentario de Joel ya que no creo que prefiera eso , lo siento

¿Esto necesita un descanso? no parece que estemos progresando mucho

Estoy bien con cualquiera de las soluciones ( sklearn.plot / sklearn.XXX.plot ). El problema principal aquí, en mi opinión, es que nadie me dice dónde pondremos cosas como plot_decision_boundary si usamos sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Interesante idea, votaré +1. Tal vez no sea tan bueno tirar todas las cosas a sklearn.plot (https://github.com/rasbt/mlxtend coloca todas las funciones de trazado en un solo módulo).

Entonces, ¿apoyaremos from sklearn.XXX.plot import plot_XXX ? ¿Apoyaremos from sklearn.XXX import plot_XXX ?

Creo que el requisito explícito de .plot en la importación es algo
otros aquí han buscado.

También está el invertido de sklearn.plot.XXX import plot_YYY

Creo que el requisito explícito de .plot en la importación es algo que otros han buscado aquí.

Entonces, ¿hemos llegado a un consenso para usar sklearn.XXX.plot (solo soporte de sklearn.XXX.plot import plot_XXX )?

También está el invertido de sklearn.plot.XXX import plot_YYY

No puedo entender

También está el invertido de sklearn.plot.XXX import plot_YYY

Quise decir que podríamos tener
sklearn.plot.model_inspection.plot_partial_dependence en lugar de
sklearn.model_inspection.plot.plot_partial_dependence. No estoy seguro si esto
proporciona cualquier beneficio / claridad.

Quise decir que podríamos tener
sklearn.plot.model_inspection.plot_partial_dependence en lugar de
sklearn.model_inspection.plot.plot_partial_dependence. No estoy seguro si esto
proporciona cualquier beneficio / claridad.

Entonces ahora tenemos 3 opciones:
(1) sklearn.plot.plot_YYY (por ejemplo, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (por ejemplo, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (por ejemplo, sklearn.tree.plot.plot_tree, no es compatible con sklearn.XXX import plot_YYY)
Votaré +1 por todas estas soluciones.
Prefiero tomar la decisión antes de 0.21 para evitar desaprobar sklearn.tree.plot_tree

No estoy seguro de que necesite un descanso, pero podría valer la pena pedir opiniones sobre el
lista de correo

No estoy seguro de que necesite un descanso, pero podría valer la pena invitar opiniones en la lista de correo.

+1. Parece que no entra en los criterios de los SLEP.

Como dije en la lista de correo, creo que también deberíamos considerar "dónde ocurre el trabajo" o cómo será la interfaz. Eso ya era bastante confuso para la dependencia parcial.
¿Debería plot_partial_dependence llamar a partial_dependence u obtener la salida de partial_dependence como entrada? Esta pregunta es una pregunta válida para básicamente todas las funciones de la trama.
La principal consideración que analizo con plot_X call compute_X es conveniente para el usuario, siempre y cuando solo quieran trazar la cosa una vez. Si no les gusta la trama y quieren cambiar algo, necesitan compute_X nuevamente, lo cual es potencialmente un desperdicio.

Entonces podríamos

• siempre toma el resultado de compute_X . inconveniente: inconveniente y propenso a errores: ¿cuál fue el orden de precisión, recuperación y umbrales nuevamente en precision_recall_curve?

• siempre lleve la entrada a compute_X y llame a compute_X desde plot_X . desventaja: es necesario volver a calcular para cada parcela.

• permitir ambos, por lo que plot_X puede tomar la entrada a compute_X y llamar a compute_X o tomar la salida de compute_X si el usuario ya la creó. Eso tiene la desventaja de complicar la firma (y posiblemente complicar la documentación). Además, si el usuario llama a plot_X para que internamente haga compute_X y luego quiera otro gráfico, debe volver a compute_X . Por lo tanto, debe anticipar que desea más de una parcela antes de llamar plot_X la primera vez. O necesita exponer el resultado de compute_X al llamar a plot_X , pero no me queda claro cómo hacerlo sin un diseño orientado a objetos

• tomemos la decisión dependiendo de lo costoso que sea compute_X, ya que para las gráficas de matriz de confusión y de dependencia parcial y las gráficas de calibración no nos importa el costo de volver a calcular, pero para las gráficas de dependencia parcial sí lo hacemos. desventaja: interfaz inconsistente.

La principal consideración que analizo con

+1000. Es un problema común que veo en el código de investigación.

De un problema de diseño, viola una separación MVC (ligeramente pedante,
perdón).

En las diversas soluciones que propone, ¿consideraría tomar una
modelo ajustado como enfoque? Siento que mitigaría el problema de
recordando el orden de los parámetros. Pero tal vez haya más
problemas.

No estoy seguro de a qué te refieres con modelo ajustado. A menudo, el resultado del cálculo no es un modelo ajustado. Podríamos definir objetos para todos los resultados del cálculo, de modo que partial_dependence devuelva un objeto PartialDependence . O un montón. Pero no devuelve un estimador.

Oh, la razón por la que menciono esto ahora: sin esta decisión, no tengo idea de cómo se verá el código de usuario, y no me gusta tomar decisiones de nomenclatura / API sin poder escribir ejemplos;)

devolver un objeto sería bastante poco aprendido, en mi humilde opinión. Pero podría resolver el problema de ubicación: podría tener métodos plot ;)

A menudo, el resultado del cálculo no es un modelo ajustado. Podríamos definir objetos para todos los resultados del cálculo, de modo que la dependencia_parcial devuelva un objeto Dependencia parcial. O un montón. Pero no devuelve un estimador.

Punto a favor.

Una opción (sin decir que sea la mejor) sería tener todas las
Las funciones de cálculo devuelven tuplas con nombre y todo el cálculo correspondiente.
las funciones toman esto. Sería algo consistente con los modernos
adiciones a la biblioteca estándar de Python.

y no me gusta tomar decisiones de nomenclatura / API sin poder escribir ejemplos;)

Soy como tú.

Entonces, si el cálculo es caro, podemos hacer el cálculo fuera de la función. Si es así, devolvemos un objeto y la función de trazado toma este objeto como entrada, ¿verdad? Votaré +1.

Y tal vez necesitemos otro tema para discutir esto :)

El beneficio de la sugerencia de confusion_matrix . Allí, una tupla no sería estrictamente necesaria, pero luego la interfaz se vuelve ligeramente inconsistente.

@ qinhanmin2014 si devolvemos objetos arbitrarios, tenemos que desaprobar el tipo de retorno para una función cada vez que creamos un ayudante de trazado. Eso parece un desastre.

Tuve una idea y luego una segunda mejor idea:
1) cree una segunda interfaz orientada a objetos que llame a la función existente, almacene el objeto y tenga un método de trazado, como

cm = ConfusionMatrix(y, y_pred)
cm.plot()

Eso resolvería el problema, pero duplicaría alguna interfaz y sería un poco confuso. En realidad, el mismo principio se puede hacer de una manera que creo que es más intuitiva:
2) haga que la función plot_ siempre haga el trabajo, use el resultado para crear una instancia de un objeto que almacena el resultado y lo traza:

plot_confusion_matrix(y, y_pred)

por lo tanto, solo trazaría y devolvería un objeto ConfusionMatrixPlotter , que almacena el resultado y tiene un método plot .
Entonces, en el simple caso de solo graficar una vez, es solo una llamada de función única. Si luego desea que los resultados hagan algo más con él, se almacenan en el objeto. Si desea trazar nuevamente, puede simplemente llamar plot en el objeto nuevamente. Si ya calculó los resultados y luego decide que desea graficar, puede instanciar ConfusionMatrixPlotter directamente.

Si bien esto expone una clase adicional para los casos de uso más complejos, creo que es una compensación razonable porque tiene una buena respuesta a todas las situaciones.

por lo tanto, solo trazaría y devolvería un objeto ConfusionMatrixPlotter, que almacena el resultado y tiene un método de trazado.

¿Por qué los usuarios deben volver a trazar los mismos datos? @amueller ajustar el formato?

@ qinhanmin2014 sí, trazarla con algo más en la misma trama, agregar etiquetas, ...

@ qinhanmin2014 sí, trazarla con algo más en la misma trama, agregar etiquetas, ...

Dudo que valga la pena considerar estos problemas de formato aquí. ¿Los usuarios pueden iniciar una pequeña parte del conjunto de datos?

Y @amueller admitiremos el paso de ejes, para que los usuarios puedan ajustar fácilmente el gráfico después de llamar a las funciones de trazado.

@ qinhanmin2014 no, muchas cosas no se pueden cambiar fácilmente después, y no necesitamos pensar en todo el formato necesariamente nosotros mismos, pero debemos permitir que los usuarios tracen algo nuevamente. Básicamente sucederá cada vez que hagas una trama. Y tener que submuestrear conjuntos de datos cada vez que quiero hacer un gráfico es un poco molesto. Y si luego cambio de opinión, tendré que volver a calcular.
Básicamente, el punto es que normalmente no puede anticipar qué es exactamente lo que quiere en su análisis exploratorio, y tener que volver a calcular todo para cambiar una visualización no parece genial.

@ qinhanmin2014 no, muchas cosas no se pueden cambiar fácilmente después, y no necesitamos pensar en todo el formato necesariamente nosotros mismos, pero debemos permitir que los usuarios tracen algo nuevamente. Básicamente sucederá cada vez que hagas una trama. Y tener que submuestrear conjuntos de datos cada vez que quiero hacer un gráfico es un poco molesto. Y si luego cambio de opinión, tendré que volver a calcular.

Sí, sé que podría ser útil, pero el problema principal aquí es que no tenemos una forma clara de admitir esta funcionalidad, y supongo que la mayoría de las funciones de trazado no requieren mucho cálculo.

Me gusta que estemos discutiendo esto con un poco más de base, pero tbh estoy
todavía no estoy del todo convencido de que incluso necesitemos tener una trama en la importación
camino en absoluto. Después de todo, parece que tenemos plot_ como prefijo para el
funciones. La pregunta también se relaciona con plot_tree: ¿por qué debería ser
¿Separado de otros códigos de exportación y visualización textual?

@ qinhanmin2014 No creo que "todavía no tenemos una buena API" sea una buena razón.
Y la dependencia parcial, la importancia de la permutación, las curvas de aprendizaje, las curvas de validación y los resultados de GridSearchCV y RandomizedSearchCV son todos ejemplos comunes que requieren mucho cálculo. Aunque para gridsearchcv y randomizedsearchcv lo obvio sería pasar el objeto o el cv_results_ , hacer el trabajo dentro de la función de trazado en esos casos parece una tontería. No estoy del todo seguro acerca de las curvas de aprendizaje y las curvas de validación tbh.

@jnothman Creo que @GaelVaroquaux quería mantener la dependencia de matplotlib confinada a un módulo y esa era una de las principales motivaciones. Todavía no tengo pensamientos muy coherentes sobre esto.

Y la dependencia parcial, la importancia de la permutación, las curvas de aprendizaje, las curvas de validación y los resultados de GridSearchCV y RandomizedSearchCV son todos ejemplos comunes que requieren mucho cálculo.

Gracias, ahora me di cuenta de que me equivoqué :)
Aunque todavía no puedo entender por qué es importante proporcionar a los usuarios una forma de trazar sin volver a calcular. Pero si otros piensan eso y hay una buena manera, votaré +1.

Me gusta que estemos discutiendo esto con un poco más de base, pero tbh estoy
todavía no estoy del todo convencido de que incluso necesitemos tener una trama en la importación
camino en absoluto. Después de todo, parece que tenemos plot_ como prefijo para el
funciones. La pregunta también se relaciona con plot_tree: ¿por qué debería ser
¿Separado de otros códigos de exportación y visualización textual?

Sí, esto también puede ser una opción. Si es así, podemos mencionar que todas las funciones que comienzan con plot_ requieren matplotlib. Otra ventaja de esta opción es que no necesitamos mover funciones existentes.

Al repasar esta discusión, estoy de acuerdo con no agregar un módulo sklearn.plot y usar el prefijo plot_ para señalar un requisito de matplotlib .

Por ejemplo, en https://github.com/scikit-learn/scikit-learn/pull/12599 , partial_dependence y plot_partial_dependence se colocarán en inspection .

De acuerdo, a menos que alguien no esté de acuerdo con esto en los próximos días, actualizaré el PR del PDP y:

• poner partial_dependence y plot_partial_dependence en sklearn.inspection
• hacer que plot_partial_dependence devuelva un grupo con los objetos fig y ax como atributos (ahora mismo los devuelve en una tupla). De esta manera, podremos mantener estas 2 funciones compatibles con versiones anteriores cuando implementemos la segunda opción de https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

¿Podemos tomar la decisión final aquí?
Propuesta acordada por @jnothman , @NicolasHug y yo (disculpas si me equivoco): sklearn.XXX.plot_YYY (soporte de sklearn.XXX import plot_YYY). Mencionaremos que todas las funciones que comienzan con plot_ requieren matplotlib.
Una gran ventaja de esta propuesta es que no necesitamos mover funciones existentes.

Dormir sobre él, creo que es bastante simple de explicar y evita la dificultad de pensar en una API de trazado compartida entre diferentes módulos.

Si hagamos eso. Cree una función de ayuda para proporcionar una
ImportError

FYI, estoy agregando sklearn.utils.check_matplotlib_support en # 12599

def check_matplotlib_support(caller_name):
    try:
        import matplotlib
    except ImportError as e:
        raise ImportError(
            "{} requires matplotlib. You can install matplotlib with "
            "`pip install matplotlib`".format(caller_name)
        ) from e

FYI, estoy agregando sklearn.utils.check_matplotlib_support en # 12599

¡Eso es genial! Gracias.