この号を開いてくれてありがとう、 gitterによると@jnothman @ amueller @ GaelVaroquauxにpingしてください

8425は、分類子の決定領域とは関係ありません。

私はplot_treeとplot_partial_dependenceをsklearn.plotに移動し、0.21で＃13335を解くことを好みます（これは重要で初心者のIMOにとって簡単ではないため、決定境界をプロットする関数を導入するかもしれません）。 他の人はどう思いますか？

sklearn.plotのスコープを制御しやすくするために、図レベルではなく、軸レベルでのみプロットを行うことを提案します。 ユーザーは、キーワードとして軸を渡します。 便宜上、軸のデフォルトは「なし」になります。 この場合のみ、プロット関数はプロットする軸/図形を生成します。

良い考えですが、既存の関数（plot_treeおよびplot_partial_dependence）と一貫性がありませんよね？

のように、図を出力/変更する必要がある場合があります。
複数のサブプロット（seabornのファセットプロットなどを参照してください。
例）。 軸に限定したい理由を教えてください。

2019年3月15日金曜日、午前2時19分、Hanmin Qin、 notifications @ github.comは次のように書いています。

この号を開いていただきありがとうございます。@ jnothmanにpingを送信してください。
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquauxによると、gitter

8425https ：//github.com/scikit-learn/scikit-learn/issues/8425はそうではありません

分類子の決定領域に関連しますか？
plot_treeとplot_partial_dependenceをsklearn.plotと
解決＃13335 https://github.com/scikit-learn/scikit-learn/issues/13335
0.21で（多分、決定境界をプロットする関数を導入します。
それは重要であり、初心者のIMOにとっては簡単ではありません）。 他の人はどう思いますか？

sklearn.plotのスコープを制御するために、プロットのみを行うことを提案します
図レベルではなく、軸レベルで。 ユーザーは軸を渡します
キーワードとして。 便宜上、軸のデフォルトは「なし」になります。 でのみ
この場合、プロット関数はプロットする軸/図形を生成しますか？

良い考えですが、既存の関数（plot_treeおよび
plot_partial_dependence）、そうですか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
。

良い考えですが、既存の関数（plot_treeおよびplot_partial_dependence）と一貫性がありませんよね？

@ qinhanmin2014 plot_treeは数字を調整していないようです。 plot_partial_dependenceは、 features基づいて複数のプロットを作成します。 ただし、軸レベルのプロットにリファクタリングすることができます。 ユーザーはplot_partial_dependence複数回呼び出して、異なる軸（および機能）を指定する必要があります。

軸に限定したい理由を教えてください。

@jnothman Seabornには、「図レベル」のプロットと「軸レベル」のプロットを明確にドキュメントがあります。 この動作をscikit-learnで適切に文書化できれば、これらの「図レベル」のプロットを作成することができます。 「図レベル」のプロットに関する私の最大の懸念は、それらを維持およびテストするのが難しいことです。 別の軸とオーバーラップする可能性のある1つの軸からの要素があります。 ただし、重複が発生する頻度が少なくなるように図を構造化することで、これを回避できます。

テストに関しては、seabornの方法で直接、matplotlibオブジェクトをテストするか、ピクセルレベルのテストを行うyellowbrickの方法でテストできます。 私はmatplotlibオブジェクトのテストを好む傾向があります。

私の2セント：

• 共通のサブパッケージ、または各サブパッケージのモジュール（sklearn.linear_models.plot、sklearn.ensemble.plot）にmatplotlibにアクセスする関数を含めるための+1。

• @thomasjpfanが述べた

  また、ずっと前に、他のプロットバックエンドに互換性のための「軸」のようなオブジェクトを与えるためにエコシステムで議論がありました。 それがどこに行ったのかわかりません。 簡単なグーグルはあまり表示されません。 最も近いのはplotly.tools.mpl_to_plotlyで、これは実際にはこの制限を必要としないので、議論は無駄だと思います。

初心者のIMOにとって重要で簡単ではないため、決定境界をプロットする関数を導入するかもしれません。

同意しますが、決定境界などの結果をプロットする方法をユーザーに示すことも、例の目標の1つだと思います。

結果の最初のプロットをすばやく実行したい場合、特にツリーのプロットなどの複雑なプロットの場合、プロット関数は優れていますが、プロットをニーズに合わせて微調整することが非常に多いため、既存の例に依存することを好みます。コードを変更します。

モジュールの名前に関しては、IMO inspectはplotよりも用途が広いです：

• なんらかの検査ではないプロットは思いつかない
• ＃12599（部分依存）はすでにinspect導入しています

IMO検査はプロットよりも用途が広い

強い意見はありません。両方の名前に+1を投票します。 たぶん、プロットはもっと簡単ですか？

ここでも、0.21より前に新しいモジュールを作成し、plot_treeとplot_partial_dependenceをそこに移動することに興味があります。 理想的には、APIについてもコンセンサスに達する必要があります（たとえば、軸レベル/図レベル）。

inspectを支持する他のポイント：

オプションとしてプロットを提供する検査ツールが必要な場合があります。 たとえば、ツリーの特性（ノード、リーフ、スプリットポイントなどの数）を出力し、オプションでmatplotlibを使用してプロットします。

提案されているように、図の代わりに軸を使用することをお勧めします（ため息、PDPを再度変更する必要があります）。 サポートとテストが簡単になります。 これはユーザーにとっては少し手間がかかりますが、より詳細な制御も可能になります。

IMO検査はプロットよりも用途が広い

強い意見はありません。両方の名前に+1を投票します。 たぶん、プロットはもっと簡単ですか？

「inspect」はPythonにロードされます（これは標準ライブラリのモジュールです）。 私
同じ名前の使用は避けます。

ここでも、0.21より前に新しいモジュールを作成し、plot_treeとplot_partial_dependenceをそこに移動することに興味があります。 理想的には、APIについてもコンセンサスに達する必要があります（たとえば、軸レベル/図レベル）。

これは0.21を遅らせるべきではありません。 私たちの目標は、早期にリリースすることです。
再び早くリリースします。

「inspect」はPythonにロードされます（これは標準ライブラリのモジュールです）。 私
同じ名前の使用は避けます。

model_inspectionを提案します。 それは私たちのmodel_selection名前とよく合います。

モデルではないもの（エンコーダー、プリプロセッサー、グリッド検索結果など）を検査したい場合があります。

inspection ？

それらもモデルです:)

各サブパッケージのパブリックプロットサブモジュールに関するGaelの提案は価値があります
検討中。

FWIW、私はinspectよりもplot方が好きです。ほとんどのユーザーにとって、それを見つけるのがより直感的だからです。 人々は、モデルを_検査_するよりもモデルを_プロット_しようとする可能性が高くなります（たとえば、検索エンジンで検索したり、IDEで可能なオートコンプリートオプションを調べたりする場合）。

各サブパッケージのパブリックプロットサブモジュールに関するGaelの提案は、検討する価値があります。

もしそうなら、どこにplot_decision_boundaryを置きましょうか？

＃12599に関しては、 @ NicolasHug partial_dependenceを新しいモジュールに含めるべきかどうか疑問です。 （つまり、ensemble.partial_dependence + plot.plot_partial_dependence）

もしそうなら、plot_decision_boundaryをどこに置きましょうか？

sklearn.plot？

私はこの解決策のためにあまり強くプッシュしたくありません。 しかし、私は同意します
「プロット」はエンドユーザーにとって発見しやすいかもしれないという感覚。

＃12599に関して、 @ NicolasHugpartial_dependenceを新しいモジュールに含めるべきかどうか疑問です。 （つまり、ensemble.partial_dependence + plot.plot_partial_dependence）

どういう意味かわかりません。 ＃12599非難するensemble.partial_dependenceの賛成でinspect.partial_dependence （もちろんinspectこの議論に基づいて変更される場合があります）。 APIも2つの実装間で異なります。

私はplotで大丈夫です、私は最終的な検査モジュールとの潜在的な高い重複について心配していますが、それ以上プッシュしません:)

各サブパッケージのパブリックプロットサブモジュールは検討する価値があります。

しかし、これまでに提案されているすべてのプロットツール（PDP、キャリブレーション、混同行列、決定領域）は、単一のモジュールに固有のものではありません。

どういう意味かわかりません。 ＃12599は、ensemble.partial_dependenceを廃止し、inspect.partial_dependenceを優先します（もちろん、inspectはこの説明に基づいて変更される可能性があります）。 APIも2つの実装間で異なります。

そのPRについて詳しく見ていないことをお詫びします。 多分inspect.partial_dependence + plot.plot_partial_dependence ？

たぶんinspect.partial_dependence + plot.plot_partial_dependence？

値の計算とプロットの明確な分離が好きです。
それは分離のようなモデル/ビューであり、それは増加するのに役立つはずです
再利用性。

Gaëlは以前にsklearn.inspect.partial_dependenceを提案していませんでした
sklearn.inspect.plot.plot_partial_dependence（他の名前に置き換えてください
必要に応じて検査するため）？ 私はこれを気にしません。

Gaëlは以前にsklearn.inspect.partial_dependenceとsklearn.inspect.plot.plot_partial_dependenceを提案していませんでしたか（必要に応じて他の名前で検査してください）？

はい、でも私は彼にplot_decision_boundaryをどこに置くべきか尋ねたところ、彼は考えを変えたようです。

参考までに、上記の推奨事項に従ってPDP PRhttps ：//github.com/scikit-learn/scikit-learn/pull/12599を更新しました。

• partial_dependenceはsklearn.model_inspection
• plot_partial_dependenceはskearn.plot

ドキュメントはこちらhttps://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

現時点では、ユーザーガイドにはplotモジュールのみが含まれていることに注意してください。 制約/動作はplot_partial_dependenceと同じであるため、 model_inspection.partial_dependenceについてのみ説明するユーザーガイドセクションを作成するのは意味がないと思います。

（これは私が心配していた重なりのようなものです）

もちろん、 partial_dependenceとplot_partial_dependenceに別々のユーザーガイドを用意したほうがよいと思われる場合は、それを行います。

参考までに、上記の推奨事項に従ってPDP PR＃12599を更新しました。
partial_dependenceはsklearn.model_inspectionにあります
plot_partial_dependenceはskearn.plotにあります

+1

現時点では、ユーザーガイドにはプロットモジュールのみが含まれていることに注意してください。 その制約/動作はplot_partial_dependenceのそれと同じであるため、model_inspection.partial_dependenceについてのみ説明するユーザーガイドセクションがあることは意味がないと思います。

+1

そこで、sklearn.plotという名前を使用することにしましたか？

sklearn.plotがsklearn全体から依存関係をインポートするのは、全員をルート名前空間に配置することを避けた場合、少し奇妙だと思います。

あなたが好むので、 sklearn.model_inspection.plotして置くplot_partial_dependence()そこに？

plotモジュールはありません、私はそれで大丈夫です

私はそれを好むと思います。 それがどのように一般化するかはまだ定かではありません。

私はそれを好むと思います。 それがどのように一般化するかはまだ定かではありません。

plot_decision_boundaryようなものを置くのに適切な場所を見つけることができる限り、私はsklearn.XXX.plot +1を投票します。

これには眠りが必要ですか？ あまり進歩していないようです

編集うーん、眠い私はそれを好まのでジョエルのコメントを読んだ、ごめんなさい

これには眠りが必要ですか？ あまり進歩していないようです

私はどちらの解決策でも問題ありsklearn.plot （ sklearn.XXX.plot ）。 ここでのIMOの主な問題は、 sklearn.XXX.plotを使用する場合、 plot_decision_boundaryようなものをどこに置くべきか誰にも教えられないということです:)

sklearn.model_inspection.plot ？

sklearn.model_inspection.plot？

面白いアイデア、私は+1に投票します。 sklearn.plotにすべてのものを投げるのはあまり良くないかもしれません（https://github.com/rasbt/mlxtendはすべてのプロット関数を単一のモジュールに入れます）。

だから私たちはfrom sklearn.XXX.plot import plot_XXXサポートしますか？ from sklearn.XXX import plot_XXXをサポートしますか？

インポートでの.plotの明示的な要件は何かだと思います
ここにいる他の人たちが探していました。

sklearn.plot.XXXからの反転もありますimportplot_YYY

インポートでの.plotの明示的な要件は、ここで他の人が求めているものだと思います。

それで、 sklearn.XXX.plotを使用するというコンセンサスに達しました（ sklearn.XXX.plotインポートplot_XXXからのサポートのみ）？

sklearn.plot.XXXからの反転もありますimportplot_YYY

理解できません。

sklearn.plot.XXXからの反転もありますimportplot_YYY

私たちは私たちが持つことができることを意味しました
sklearn.plot.model_inspection.plot_partial_dependenceではなく
sklearn.model_inspection.plot.plot_partial_dependence。 これかどうかわからない
あらゆる利点/明確さを提供します。

私たちは私たちが持つことができることを意味しました
sklearn.plot.model_inspection.plot_partial_dependenceではなく
sklearn.model_inspection.plot.plot_partial_dependence。 これかどうかわからない
あらゆる利点/明確さを提供します。

したがって、3つのオプションがあります。
（1）sklearn.plot.plot_YYY（例：sklearn.plot.plot_tree）
（2）sklearn.plot.XXX.plot_YYY（例：sklearn.plot.tree.plot_tree）
（3）sklearn.XXX.plot.plot_YYY（たとえば、sklearn.tree.plot.plot_tree、sklearn.XXXからのサポートはありませんimport plot_YYY）
これらすべてのソリューションに+1票を投じます。
sklearn.tree.plot_treeの非推奨を避けるために、0.21より前に決定することを好みます

眠りが必要かどうかはわかりませんが、
メーリングリスト

眠りが必要かどうかはわかりませんが、メーリングリストで意見を求める価値があるかもしれません

+1。 SLEPの基準には当てはまらないようです。

メーリングリストで言ったように、「どこで仕事をするのか」やインターフェースはどうなるのか、本当に考えるべきだと思います。 それは部分的な依存についてはすでにかなり不明確でした。
plot_partial_dependenceはpartial_dependence plot_partial_dependence呼び出す必要がありますか、それともpartial_dependence出力を入力として取得する必要がありますか？ この質問は、基本的にすべてのプロット関数に有効な質問です。
@NicolasHugと話し合う主な考慮plot_X compute_X呼び出すことは、ユーザーにとって便利であるということです。 プロットが気に入らず、何かを変更したい場合は、もう一度compute_Xする必要がありますが、これは無駄になる可能性があります。

だから私たちはどちらか

• 常にcompute_Xの結果を取ります。 欠点：不便でエラーが発生しやすい：precision_recall_curveでの適合率、再現率、およびしきい値の順序はどのようなものでしたか？

• 常にへの入力を取るcompute_Xと呼んでcompute_Xからplot_X 。 欠点：プロットごとに再計算する必要があります。

• そう、両方を許可するplot_Xへの入力のいずれか取ることができますcompute_Xに、コールをcompute_Xかの出力取るcompute_Xユーザーが既にそれを作成した場合。 これには、署名が複雑になるという欠点があります（おそらく、署名の文書化も複雑になります）。 また、ユーザーがplot_X呼び出して、内部でcompute_Xを実行し、別のプロットが必要な場合は、もう一度compute_Xを実行する必要があります。 したがって、最初にplot_X呼び出す前に、複数のプロットが必要であることを予測する必要があります。 それとも、結果公開する必要がcompute_X呼び出すときにplot_X 、それは、オブジェクト指向設計せずにそれを行う方法を私に不明です

• 混同行列、部分依存プロット、およびキャリブレーションプロットについては、再計算のコストは気にしませんが、部分依存プロットについては、compute_Xのコストに応じて決定します。 欠点：一貫性のないインターフェース。

@NicolasHugと話し合う主な考慮

+1000。 これは、リサーチコードでよく見られる問題です。

設計上の問題から、MVCの分離に違反しています（やや衒学的、
ごめん）。

あなたが提案するさまざまな解決策の中で、あなたは
アプローチとして適合モデル？ 私はそれがの問題を軽減するだろうと感じています
パラメータの順序を覚えています。 しかし多分追加があります
問題。

フィットモデルの意味がわかりません。 多くの場合、計算の出力は適合モデルではありません。 partial_dependenceがPartialDependenceオブジェクトを返すように、すべての計算結果に対してオブジェクトを定義できます。 または束。 ただし、推定量は返されません。

ああ、私が今これを取り上げる理由：この決定がなければ、ユーザーコードがどのようになるかわかりません。また、例を書き留めることができずに命名/ APIの決定を行うのは好きではありません;）

オブジェクトを返すことは、sklearnのようなものではありません。 しかし、それは場所の問題を解決するかもしれません：それはplotメソッドを持つことができます;）

多くの場合、計算の出力は適合モデルではありません。 すべての計算結果に対してオブジェクトを定義して、partial_dependenceがPartialDependenceオブジェクトを返すようにすることができます。 または束。 ただし、推定量は返されません。

取られたポイント。

1つのオプション（それが最良のものであるとは言わない）は、すべてを持っていることです
計算関数は、名前付きタプルと対応するすべての計算を返します
関数はこれを取ります。 それは現代と幾分一致しているでしょう
Python標準ライブラリへの追加。

そして私は例を書き留めることができずに命名/ APIの決定をするのが好きではありません;）

私はあなたのようです。

したがって、計算にコストがかかる場合は、関数の外部で計算を行うことができます。 もしそうなら、オブジェクトを返し、プロット関数はこのオブジェクトを入力として受け取りますよね？ +1に投票します。

そして多分私達はこれを議論するために別の問題が必要です:)

@GaelVaroquauxの提案の利点は、タプルの解凍のためにユーザーがコードを変更する必要がない可能性があることです。 ただし、 confusion_matrixように返されるオブジェクトが1つしかない場合は、機能しません。 タプルは厳密には必要ありませんが、インターフェイスが少し不整合になります。

@ qinhanmin2014任意のオブジェクトを返す場合、プロットヘルパーを作成するたびに、関数の戻り型を非推奨にする必要があります。 それは混乱のようです。

私には1つのアイデアがあり、次に2つ目のより良いアイデアがありました。
1）既存の関数を呼び出し、オブジェクトを格納し、次のようなプロットメソッドを持つ2番目のオブジェクト指向インターフェイスを作成します。

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

それは問題を解決しますが、いくつかのインターフェースを複製し、それは少し不明確になります。 実際、同じ原則は、私がより直感的だと思う方法で行うことができます。
2） plot_関数に常に作業を行わせ、結果を使用して、結果を格納し、それをプロットするオブジェクトをインスタンス化します。

plot_confusion_matrix(y, y_pred)

したがって、プロットして、結果を格納し、 plotメソッドを持つConfusionMatrixPlotterオブジェクトを返します。
したがって、1回だけプロットするという単純なケースでは、それは1回の関数呼び出しです。 その後、結果に他の処理を実行させたい場合は、オブジェクトに格納されます。 もう一度プロットしたい場合は、オブジェクトに対してplotをもう一度呼び出すことができます。 すでに結果を計算してからプロットすることにした場合は、 ConfusionMatrixPlotter直接インスタンス化できます。

これにより、より複雑なユースケース用の追加のクラスが公開されますが、すべての状況に適切に対応できるため、妥当なトレードオフだと思います。

したがって、単にプロットし、結果を格納し、プロットメソッドを持つConfusionMatrixPlotterオブジェクトを返します。

ユーザーが同じデータを再度プロットする必要があるのはなぜですか？ @amuellerはフォーマットを調整しますか？

@ qinhanmin2014はい、フォントを大きくし、色を変更し、同じプロットで他のものと一緒にプロットし、ラベルを追加します...

@ qinhanmin2014はい、フォントを大きくし、色を変更し、同じプロットで他のものと一緒にプロットし、ラベルを追加します...

ここでこれらのフォーマットの問題を検討する価値があるかどうかは疑問です。 ユーザーはデータセットのごく一部を開始できますか？

また、 @ amuellerは軸の

@ qinhanmin2014いいえ、後で簡単に変更できないものがたくさんあります。すべてのフォーマットについて自分で考える必要はありませんが、ユーザーが何かをもう一度プロットできるようにする必要があります。 それは基本的にあなたがプロットをするときはいつでも起こります。 また、プロットを実行するたびにデータセットをサブサンプリングする必要があるのは少し面倒です。 そして、後で気が変わった場合でも、再計算する必要があります。
基本的に重要なのは、通常、探索的分析で何が必要かを正確に予測することはできず、視覚化を変更するためにすべてを再計算する必要があるとは思えないということです。

@ qinhanmin2014いいえ、後で簡単に変更できないものがたくさんあります。すべてのフォーマットについて自分で考える必要はありませんが、ユーザーが何かをもう一度プロットできるようにする必要があります。 それは基本的にあなたがプロットをするときはいつでも起こります。 また、プロットを実行するたびにデータセットをサブサンプリングする必要があるのは少し面倒です。 そして、後で気が変わった場合でも、再計算する必要があります。

はい、私はそれが役に立つかもしれないことを知っています、しかしここでの主な問題は私たちがこの機能をサポートするクリーンな方法を持っていないということです、そして私はほとんどのプロット関数が多くの計算を必要としないと思いますか？

私はこれについてもう少し根拠を持って議論しているのが好きですが、私は
まだ完全に私たちがインポートでプロットを持っている必要があることを確信していません
まったくパス。 結局のところ、plot_をプレフィックスとして持っているようです
関数。 質問はplot_treeにも関連しています：なぜそれが必要なのですか
他のエクスポートおよびテキストの視覚化コードから分離されていますか？

@ qinhanmin2014 「まだ良いAPIがない」というのは正当な理由ではないと思います。
また、部分的な依存関係、順列の重要性、学習曲線、検証曲線、およびGridSearchCVとRandomizedSearchCVの結果はすべて、多くの計算を必要とする一般的な例です。 gridsearchcvとrandomizedsearchcvの場合、オブジェクトまたはcv_results_いずれかを渡すことは明らかですが、そのような場合にプロット関数内で作業を行うことは無意味に思えます。 学習曲線と検証曲線tbhについては完全にはわかりません。

@jnothman私は@GaelVaroquauxモジュールに限定さmatplotlibの依存関係を維持したい、それが主な動機の一つだったと思いますか？ 私はまだこれについてあまり首尾一貫した考えを持っていません。

また、部分的な依存関係、順列の重要性、学習曲線、検証曲線、およびGridSearchCVとRandomizedSearchCVの結果はすべて、多くの計算を必要とする一般的な例です。

おかげで、私は今私が間違っていることに気づきました:)
再計算せずにプロットする方法をユーザーに提供することが重要である理由はまだ理解できませんが。 しかし、他の人がそう考えて、良い方法があれば、私は+1に投票します。

私はこれについてもう少し根拠を持って議論しているのが好きですが、私は
まだ完全に私たちがインポートでプロットを持っている必要があることを確信していません
まったくパス。 結局のところ、plot_をプレフィックスとして持っているようです
関数。 質問はplot_treeにも関連しています：なぜそれが必要なのですか
他のエクスポートおよびテキストの視覚化コードから分離されていますか？

はい、これもオプションになります。 もしそうなら、 plot_で始まるすべての関数にはmatplotlibが必要であると言えます。 このオプションのもう1つの利点は、既存の関数を移動する必要がないことです。

この議論を検討すると、 sklearn.plotモジュールを追加しないことに同意し、プレフィックスplot_を使用してmatplotlib要件を通知します。

たとえば、 https：//github.com/scikit-learn/scikit-learn/pull/12599では、 partial_dependenceとplot_partial_dependenceはinspection配置されます。

わかりました。次の日に誰かがこれに同意しない場合を除いて、PDPPRを更新します。

• partial_dependenceとplot_partial_dependence両方をsklearn.inspection
• plot_partial_dependenceがfig axオブジェクトとhttps： //github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520から2番目のオプションを実装するときに、これら2つの関数の下位互換性を維持でき

ここで最終決定を下すことができますか？
@ jnothman 、 @ NicolasHug 、および私が同意した提案（間違っている場合はお詫びします）：sklearn.XXX.plot_YYY（sklearn.XXX import plot_YYYからのサポート）。 plot_で始まるすべての関数にはmatplotlibが必要であることに言及します。
この提案の主な利点は、既存の機能を移動する必要がないことです。

その上で眠るのは説明するのに十分簡単だと思います、そしてそれは異なるモジュール間で共有されたプロットAPIを考えることの難しさを避けます。

はい、そうしましょう。 ヘルパー関数を作成して、より役立つものを提供します
ImportError

参考までに、＃12599にsklearn.utils.check_matplotlib_supportを追加します

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

参考までに、＃12599にsklearn.utils.check_matplotlib_supportを追加します

それは素晴らしいことです！ ありがとう。