Numpy: リクエスト：セマンティックバージョニングを使用する

numpyはセマンティックバージョニングを使用していると見なすことができますが、先頭に1が付いていますか？

ほとんどすべてのコア科学Pythonプロジェクトは、NumPyが行うことを実行することに注意してください。それが非常に破壊的でない限り、2、3のリリース後に非推奨のコードを削除し、メジャーバージョン番号を上げるだけです。

非推奨ポリシーの変更を提案しているのか、それとも現在1.14.09ではなくバージョン14.0.0にする必要があると考えているのかわからない。

後者：NumPyは今ではおおよそバージョン14になっているはずです。 ただし、この規則は将来のリリースでのみ採用することを提案します。

ところで：NumPyの前身であるNumericは、セマンティックバージョニングを使用し、約10年でバージョン24になりました。 NumPyへの移行でこれが変更された理由はわかりません。

私の印象では、Pythonプロジェクトの大多数はセマンティックバージョニングを使用していません。 たとえば、Python自体はセマンティックバージョニングを使用しません。 （私はsemverを使用する主流のオペレーティングシステムやコンパイラも知りません-何か考えていますか？）semverの支持者がそれをマーケティングする素晴らしい仕事をして、多くの開発者にそれが良いと思うように導いたことに同意しますアイデアですが、AFAICTは、左パッドよりも大きいプロジェクトでは本質的に実行不可能です。私は、semverの人々が現在、従来のMAJOR.MINOR.MICRO形式を「所有」しており、他のすべての人が何かに切り替える必要があるという考えに強く異議を唱えています。そうしないと。

「セマンティックバージョニングと間違えられないリリースラベリングスキーム」の意味の例を挙げていただけますか？ 数字の代わりに名前を使用しますか？ 日付ベースのバージョン管理を引用していますが、私が見た中で最も一般的なスキームは、たとえばTwistedとPyOpenSSLで使用されているもので、現在はそれぞれ17.9.0と17.5.0です。 それらは私には完全にもっともらしいsemverバージョンのように見えます...

そして、これがユーザーにどのようなメリットをもたらすかについて詳しく説明していただけますか？ この架空の将来では、すべてのリリースに、今と同じように、大多数のユーザーには関係のない重大な変更が加えられます。 数か月ごとにメジャー番号を増やすことで、どのような有用な情報を伝えることができるでしょうか。 「これはおそらく誰かを壊しますが、おそらくあなたを壊しません」？ それらの大部分が少なくとも1人のコードを破壊するという歴史的な必然性を考えると、バグ修正リリースのメジャーバージョンもバンプする必要がありますか？ 実際に混乱している「ソフトウェア開発者、ソフトウェアユーザー、ソフトウェア配布の管理者」の例を挙げてください。

メーリングリストはこの議論のより適切な場所であり、おそらく実際に変更を加える前にそこで議論する必要があることに注意してください。ただし、ここでのコメントは、どのような問題が必要かを理解するのに役立ちます。その議論で対処する。

@njsmith私たちが同意しない唯一の事実は、セマンティックバージョニングが今日のデフォルトの仮定であるかどうかということのようです。 これには、デフォルトである（またはデフォルトではない）コミュニティのより明確な定義が必要です。 私が関心を持っているソフトウェア管理のレベルは、配布管理とシステム管理です。これは、ユーザーが自分のコンテキストで最も適切なバージョンを決定する場所です。

セマンティックバージョニングがデフォルトであるという結論に至った非公式の調査は、科学計算設備の管理者と話すことで構成されていました。 私も思い描いた
より経験的なアプローチ（最近のDebianインストールでパッケージをリストし、それらのいくつかをランダムに選択してバージョン管理アプローチを調査する）ですが、セマンティックバージョニングを使用するかどうかを明確に述べているプロジェクトはほとんどないため、これは非常に困難であることがわかりました。

あるシステム管理者からのコメントは、特に関連性があると私に印象づけました。彼は、インストールするバージョンを決定するために、セマンティックバージョニング以外の規則は役に立たないと述べました。 システム管理者は、各パッケージを詳細に調査することも（時間と能力が不足している）、すべてのユーザーに相談することもできません（ユーザーが多すぎます）。 彼らは統一されたポリシーを採用する必要があり、これはセマンティックバージョニングの仮定に基づく傾向があります。 たとえば、コンピューティングクラスターの管理者は、メジャーバージョン番号を変更して更新を適用する前に、個人的に知っている数人の「パワーユーザー」に確認すると言っていました。

特に科学的なPythonユーザーに関して実際に混乱している人々の例としては、職場の同僚、会議で会う人々、電子メールでアドバイスを求める人々、私のクラスの学生など、たくさんの人々がいます。 これは通常、「あなたがPythonの専門家であることを知っていますが、問題について私を助けてくれませんか？」で始まります。 その問題は、あるコンピューターでは機能するが、別のコンピューターでは機能しないスクリプトであることが判明しました。 これらの人々のほとんどは依存関係の問題をまったく考慮していませんが、実際に2つのインストールのバージョン番号を比較して、「小さな違い」だけを見つけた人もいます。

@ eric-wieserと@rgommersが指摘したように、私の要求は、最初の「1」を要求することとほぼ同義です。 NumPyバージョンから削除されます。 言い換えれば、NumPyの事実上のバージョン管理は、ポリシー決定の結果ではなく、したがっておそらく厳密には行われていなくても、すでにセマンティックバージョニングを使用しています。 ただし、NumPyが現在の開発ワークフローにほとんど変更を加えることなくセマンティックバージョニングを採用できることを示唆しています。

あるシステム管理者からのコメントは、特に関連性があると私に印象づけました。彼は、インストールするバージョンを決定するために、セマンティックバージョニング以外の規則は役に立たないと述べました。

残念ながら、セマンティックバージョニングもこれには役に立ちません:-(。私は髪を分割したり誇張したりするつもりはありません。それは本当の問題だと完全に理解しています。しかし、問題が本当だからといって、それが解決策を持っているとは限りません。基本的に、「このソフトウェアをアップグレードする必要がありますか？」という質問を単純な機械的チェックに要約することはできません。これは幻想です。semverを使用するプロジェクトは、すべてのユーザーがすぐにアップグレードする必要があるメジャーリリースを定期的に作成し、マイナーで定期的に重大な変更を加えます。リリース。

システム管理者は、各パッケージを詳細に調査することも（時間と能力が不足している）、すべてのユーザーに相談することもできません（ユーザーが多すぎます）。 彼らは統一されたポリシーを採用する必要があり、これはセマンティックバージョニングの仮定に基づく傾向があります。 たとえば、コンピューティングクラスターの管理者は、メジャーバージョン番号を変更して更新を適用する前に、個人的に知っている数人の「パワーユーザー」に確認すると言っていました。

私はこの部分が好きです:-)。 semverの哲学については同意できないと思いますが、さまざまなバージョン管理スキームの具体的な効果と、どの結果が最も望ましいかについて話し合う方がはるかに簡単です。

semverの概念は、このポリシーとはあまり関係がないと思います。話したシステム管理者は、実際にすべてのプロジェクトをチェックして、semverを使用しているかどうかを確認しますか？ あなたが言ったように、ほとんどのプロジェクトは、どれがそうするかさえ見分けるのが難しいです。 また、ポリシーは、semverが存在するずっと前からsysadminsが使用していたものと同じです。 このポリシーのより良い特徴は、メジャーリリースは「大きい」、マイナーリリースは「小さい」という古代の伝統とともに、「アップグレードにどれだけ注意するかについてのプロジェクトの推奨事項に従う」ことだと思います。

NumPyプロジェクトの推奨事項は、システム管理者が新機能リリースにアップグレードする必要があることです。したがって、この逸話から私が得たのは、現在の番号付けスキームが必要なものを正確に伝達しており、semverに切り替えても...

@njsmith OK、哲学から実用性に目を向けましょう。ソフトウェア開発者、システムメンテナー、およびソフトウェアユーザー間のコミュニケーションにおけるソフトウェアバージョン番号の役割は何ですか？

ここでも、意見に大きな違いがあるようです。 あなたにとって、システムのメンテナとユーザーに指示を与え、バージョン番号を使用して指示を伝えるのは開発者です。 私にとって、すべてのプレイヤーは自分の基準に従って決定する必要があり、バージョン番号は最も粗いレベルでの事実上のコミュニケーションの手段として機能する必要があります。

NumPyにはセキュリティ上の影響がないことを考えると、NumPyプロジェクトが普遍的な推奨事項を提供する方法と理由がわかりません。 人と機関には異なるニーズがあります。 そのため、ArchLinuxとCentOSの両方があり、更新ポリシーが大きく異なります。

@khinsen oldnumericパッケージは引き続き完全に機能し、次の方法でインストールできます。

pip install oldnumeric

おそらくこれは、numpyへのインターフェースがPython / Cythonに制限されており、何も変更されていない、提案された「安定したnumpy」である可能性があります。 もちろん、oldnumericでコードを書くことは非常に難解ですが、両方の方法でコードを書くことはできません。

@xoviat本当ですが、それは別の問題です。 ここでの私のポイントは、ソフトウェアの保存ではなく、ソフトウェア管理におけるさまざまなプレーヤー間のコミュニケーションです。

質問：システム管理者として（個人のマシンだけでも）、パッケージがバージョン1.8からバージョン1.9に完全なAPIレイヤーをドロップすることを期待しますか？

「はい」と答えた人のために、2番目の質問：これまでにこれを行ったnumpy以外のソフトウェアに名前を付けることができますか？

ところで、MMTKがいつの日か機能しなくなった理由を尋ねるメールをたくさん受け取ったので、多くの人がこれに噛まれたことは間違いありません。 これらすべての人々は、深刻な結果を予期することなく、ソフトウェアインストールの定期的な更新を行っていました。

しかし、 oldnumericドロップdiagonalなどの一部の操作のコピー/ビューセマンティクスを変更することです。 NumPyのバージョン（マイナーバージョン番号の変更！）に応じて異なる結果を返すコードは、本当に悪夢です。

ところで、誰もその話を知らないので、 pip install oldnumericは2日前から機能します。これは、

パッケージが完全なAPIレイヤーをバージョン1.8からバージョン1.9にドロップすることを期待しますか？

どのレイヤーを参照していますか？

これまでにこれを行ったnumpy以外のソフトウェアに名前を付けることができますか？

SciPyはweaveとmaxentropyパッケージをドロップし、 pandasは定期的に主要な機能を壊します。 もっと目立つ例はたくさんあると思います。 編集：たとえば、Python自体。https ：//docs.python.org/3/whatsnew/3.6.html#removedを参照して

ところで、MMTKがいつの日か機能しなくなった理由を尋ねるメールをたくさん受け取ったので、多くの人がこれに噛まれたことは間違いありません。 これらすべての人々は、深刻な結果を予期することなく、ソフトウェアインストールの定期的な更新を行っていました。

その変更は作成から約10年であり、別のバージョン管理スキームがここで違いを生むことはありません。

非推奨の機能を削除することは、（古い）コードのごく一部を壊すことと、コードベースを維持しやすくすることの間のトレードオフです。 全体として、私たちが誤りを犯している場合、保守的な側面でそれを行っている可能性があります。 numpyを使用する長年の大規模な企業コードベースにも対処しなければならなかった人として、私はあなたの痛みを感じますが、あなたは絶対に解決策ではないものを主張しています（そして一般的に完全な解決策はありません;ユーザーを教育するバージョンの固定や非推奨の警告の確認などが最善の方法です）。

どのレイヤーを参照していますか？

数値/ numarrayのサポート

@rgommers申し訳ありませんが、「SciPyエコシステム以外の別の例」と言うべきでした。

また、 oldnumericサポートを終了することについても不満はありません。 メジャーバージョン番号を変更せずにこれを行うことに不満を持っています。

それはどのような違いをもたらしたでしょうか？ それは人々をリリースノートを読まずに更新することを躊躇させたでしょう。 Pythonコードを使用している（ただし開発していない）すべての人は、これを注意すべき兆候と見なしているでしょう。

SciPyエコシステムには、開発を積極的にフォローしていない膨大な数の目立たないユーザーがいることを忘れないでください。 PythonとNumPyは、それらのlsおよびgccと同じ性質のインフラストラクチャアイテムです。 そして、多くの場合、それよりも少ないです。彼らは、たまたまPythonで書かれていて、たまたまNumPyに依存しているソフトウェアを使用しており、壊れると完全に失われます。

@rgommers申し訳ありませんが、「SciPyエコシステム以外の別の例」と言うべきでした。

SciPyエコシステムの外にあるPythonリリースノートへのリンクを使用して返信を編集しました。

それはどのような違いをもたらしたでしょうか？ それは人々をリリースノートを読まずに更新することを躊躇させたでしょう。 Pythonコードを使用している（ただし開発していない）すべての人は、これを注意すべき兆候と見なしているでしょう。

これは単にそうではありません。 1.12、1.13、1.14などの代わりに12.0、13.0、14.0がある場合、ユーザーはそれに慣れ、以前と同じアップグレード戦略を使用します。 大多数は、突然すべてがはるかに保守的になるわけではありません。

SciPyエコシステムには、開発を積極的にフォローしていない膨大な数の目立たないユーザーがいることを忘れないでください。 PythonとNumPyは、それらのlsやgccと同じ性質のインフラストラクチャアイテムです。 そして、多くの場合、それよりも少ないです。彼らは、たまたまPythonで書かれていて、たまたまNumPyに依存しているソフトウェアを使用しており、壊れると完全に失われます。

すべて真実であり、バージョン番号によって魔法のように修正できるわけではありません。 彼らがpip install --upgrade numpyを実行した場合、彼らは彼らが何をしているのかを知る必要があります（そしてこれはとにかくバージョン番号を表示していません）。 それが彼らのパッケージングシステムであるならば、彼らはまともなテストスイートを持っていない（またはそれが実行されなかった）ことを壊すソフトウェアの問題を見ています。

今すぐバージョン管理スキームを変更することのその他の欠点：

• メンテナンスポリシーを変更せずにバージョン管理を変更すると、役立つというよりも混乱することになります
• 現在、基本的にPythonの主導に従い、エコシステム全体の残りの部分と同じことを行っています。 それは良いことです
• おそらく最も重要なのは、実際に大きな変更を通知する機能が失われることです。 ABIを壊すリリースのように、2.xに使用する種類。

私のベースラインリファレンスはPythonではなく、典型的なソフトウェアインストールです。 私が言ったように、多くの（おそらくほとんどの）ユーザーにとって、NumPyはgnu-coreutilsやgccのようなインフラストラクチャです。 特にSciPyエコシステムのコンテキストでバージョン番号を解釈することはありません。

約300個のパッケージがインストールされているDebian9システムを簡単にチェックしました。 それらの85％には、整数で始まりドットが続くバージョン番号があります。 最も一般的な整数プレフィックスは、1（30％）、2（26％）、0（14％）、および3（13％）です。 NumPyが一般的な期待に準拠したバージョン番号付けスキーム（つまり、セマンティックバージョニングまたは厳密な近似）を採用した場合、それは間違いなく際立っており、注意して扱われます。

また、Debianがインストールしたソフトウェアで、私にとってこれまでに問題が発生した唯一の更新は、SciPyエコシステムでした。ただし、自家製のorg-mode拡張機能を破壊するorg-modeの変更をもたらしたEmacsの更新は例外です。 したがって、全体的に低いバージョン番号のプレフィックスは、最も広く使用されているソフトウェアがNumPyやその仲間よりもはるかに安定していることを示しているようです。

SciPyエコシステム全体の均一性は確かに重要ですが、エコシステム全体が外の世界の期待に準拠したバージョン管理スキームを採用することを望んでいます。 私はNumPyを最も基本的な部分と見なしているため、NumPyから始めています。 それは何よりもさらに多くのインフラストラクチャです。

最後に、関数のセマンティクスの変更は、ABIの変更よりもはるかに重要な変更であると考えています。 前者は、何百人ものユーザーにデバッグの悪夢を引き起こし、プログラムが何年にもわたって検出されない間違った結果を生成する可能性があります。 後者は、何かを修正する必要があることを明確に示すエラーメッセージにつながります。

それらの標準によれば、Python言語で私が知っているセマンティクスの唯一の変更は2から3に起こったため、NumPyはPythonの先導にさえ従いません。

最後に、関数のセマンティクスの変更は、ABIの変更よりもはるかに重要な変更であると考えています。 前者は、何百人ものユーザーにデバッグの悪夢を引き起こし、プログラムが何年にもわたって検出されない間違った結果を生成する可能性があります。 後者は、何かを修正する必要があることを明確に示すエラーメッセージにつながります。

これはやらないように一生懸命頑張っています。 一部の機能が削除されたときに明らかな破損が発生する可能性がありますが、数値結果を黙って変更することはできません。 それは私たちが斜めのビューの変更から学んだことの1つです-それは後知恵の間違いでした。

それは間違いなく目立ち、注意して扱われるでしょう。

私はまだ同意しません。 Debianでも、これは私たちのユーザーベースにとって間違いなく「典型的なソフトウェアインストール」ではありません（Windows上のAnacondaのようなものです）。 また、ユーザーがバージョン番号を正常に表示することすらできないという上記の私の議論を無視しているようです（ pip install --upgradeでもパッケージマネージャーでも）。

また、他の大規模な依存関係チェーンではなく、OSユーティリティやGUIプログラムなどを使用しているため、他のすべてが壊れることはないという経験があります。 たとえば、JavaScript / NodeJSエコシステム全体はおそらくPythonのものよりも壊れやすいでしょう。

ところで、MMTKがいつの日か機能しなくなった理由を尋ねるメールをたくさん受け取ったので、多くの人がこれに噛まれたことは間違いありません。

これは、ここでの微妙な点の良い例です。 私の知る限り、numerical / numarray互換性コードの削除によって影響を受けたのは、MMTKと他のプロジェクトだけです。 何人のユーザーがいると思いますか？ 100？ 1000？ NumPyには数百万がありますが、おそらくユーザーの0.1％がこの削除の影響を受けましたか？ これは間違いなくゼロではありません。小さいという事実は、それが問題ではないという意味ではありません。あらゆる方法で100％のユーザーを永遠にサポートできればと思います。 また、ユーザーからの苦情を100％受け取ることは、あなたにとって特に苦痛であることを理解しています。

しかし、これについてメジャーバージョン番号を上げると、ユーザーの99.9％になり、オオカミを泣かせただけです。 誤検知です。 その0.1％のユーザーにとってOTOHは本当に重要でした。 それでも、最善の努力にもかかわらず、マイクロリリースでユーザーの0.1％以上を壊すことは珍しくありません。 どうしようか？

バージョン番号の鈍器を介してこれらのニュアンスを伝えることは単純に不可能です。 正当な理由から、アップグレードによってコードが破損するかどうかをすばやく判断する方法を誰もが望んでいます。 Semverは、そうすることを約束しているので人気があります。 流行のダイエットが癌を治すことができると考えるのが一般的であるのと同じ理由でそれは人気があります。 semverもその約束を果たしてくれたらいいのにと思います。 しかし、そうではありません。優れたエンジニアになりたいのであれば、その現実の複雑さに対処する必要があります。

NumPyプロジェクトが普遍的な推奨を提供する方法と理由がわかりません。 人と機関には異なるニーズがあります。

バージョン番号が1つしかないため、普遍的な推奨事項を示します。したがって、定義上、それを使用して行うことはすべて普遍的な推奨事項です。 それは私たちが制御できるものではありません。

その栄誉は、 diagonalなどの一部の操作のコピー/ビューセマンティクスを変更することです。

IIRCは、コードが壊れたという誰かからの苦情を文字通り受け取っていません。 （たぶん一人？）誰も影響を受けなかったという意味ではありません。明らかに、変更について不平を言う人は、一般的に影響を受ける人のごく一部にすぎませんが、実際の大まかな代理として苦情を使用すると、世界に影響を与えるなら、これがトップ50になるとは思わない。

そしてところで、深い歴史を検索すると、それよりもはるかにひどい変更を見つけることができると確信しています:-)。

また、Debianがインストールしたソフトウェアで、私にとってこれまでに問題が発生した唯一の更新は、SciPyエコシステムでした。ただし、自家製のorg-mode拡張機能を破壊するorg-modeの変更をもたらしたEmacsの更新は例外です。

敬意を表して、これはNumPyとDebianの使い方よりも、NumPyとDebianの使い方の方が多いと思います。 私はDebianが大好きで、20年近く使っていますが、壊れたものが何回あるかは数えられません。 ちょうど先週、新しいgnomeに関するいくつかの奇妙な問題が私のログインスクリプトを壊し、他のいくつかのアップグレード-Werrorを使用した後、警告動作に小さな変更を加えるなどの理由で、gccリリースのように少数の人々を壊さないようなものはないと思います（微妙に依存する可能性があります）最適化パス間の相互作用など）は、重大な変更になります。

したがって、全体的に低いバージョン番号のプレフィックスは、最も広く使用されているソフトウェアがNumPyやその仲間よりもはるかに安定していることを示しているようです。

全体的に低いバージョン番号のプレフィックスは、最も広く使用されているソフトウェアがsemverを使用しないためです。

最後に、関数のセマンティクスの変更は、ABIの変更よりもはるかに重要な変更であると考えています。 前者は、何百人ものユーザーにデバッグの悪夢を引き起こし、プログラムが何年にもわたって検出されない間違った結果を生成する可能性があります。 後者は、何かを修正する必要があることを明確に示すエラーメッセージにつながります。

はい、そういうわけで私達はそのような変化に非常に警戒しています。

ここでは、視点にいくつかの断絶があります。私たちは常に物事を意地悪に変えていると思っているようです。下位互換性などは気にしないでください。私はそれを尊重できます。 それはあなたの経験を反映していると思います。 しかし、私たちの経験では、このような変更には細心の注意を払っています。ユーザーと話すとき、あなたの視点を持っているのは約5％であり、numpyが安定性で良い仕事をしていると感じているのは約95％です。または、それはあまりにも良い仕事をしていて、物事を壊すことをもっと喜んでするべきだということ。 おそらく、私たちがあなたを失望させたとしても、私たちはその最後のグループも失望させていることを知って安心することができます:-)。

Emacsアップデートを除いて

さて、話題から外れると、それは安定性の反対側の例として役立ちます。 Emacsは、Stallmanの変更に対する抵抗のために何年も静的であり、その結果、xEmacsフォークが作成されました。 私自身の道はEmacs-> xEmacsでした、-> Vim;）時期尚早の化石化も、私が当時Debianの使用をやめた理由です。 いくつかの点では、変更は単に必要ではないか、必要さえありません。クローゼットの中に隠された古いハードウェアでBSDの古いバージョンを実行している人々がいると思います。 しかし、そのような場所がたくさんあるとは思いません。

現在の問題に当てはまりますが、バージョン管理スキームを変更しても実際には何の違いもないと思います。 より生産的な道は、近代化の問題に取り組むことかもしれません。 @khinsenメインプロジェクトの更新を受け入れる方法はわかりますか？ もしそうなら、私たちはあなたがそれをするのを助けることができる方法を探求するべきだと思います。

私はでプロジェクトを更新しようとしています
https://github.com/ScientificPython。 Pythonコードを更新する必要があります
古いCAPIを使用しました（つまり、古いものです。Py_PROTOなどの一部の関数は
2000年から）。 PRはもちろん大歓迎ですが、誰かかどうかはわかりません
それに時間を費やしたいと思っています。

彼が提起したと思うより大きな問題は、「多くの
プロジェクト」（すべてのプロジェクトがあるため、正確にどこにあるのかわかりません
私が見たPythonのサポート3）これも更新が必要です。 どうですか
NumPy開発者の時間を割り当てるプロジェクトを決定しましたか？ そして私も
彼の中心的な主張が無効だとは思わないでください：SciPyは
古いFortranプロジェクト（など）を単にコピーして貼り付けることができるという事実
fftpack）ほとんどまたはまったく変更なし。 これらが言うで書かれていた場合
「fortran2」と「fortan3」のみをコンパイルした新しいコンパイラは、
重要な問題でした。

とはいえ、これらの問題は実際にはNumPyのせいではありません。 彼が持っているものにもかかわらず
NumPy 1.13をインストールしても、oldnumericはまだすべてのテストに合格しています。
NumPyがここの犯人ではないことを示しています。 古い数値APIは
文字通り10年以上前（おそらく20年に近づいています！）、そしてそれはまだ
最新のNumPyで動作しますが、NumPyAPIはおそらく安定していると思います
足りる。

@charris 「何も変更しない」ことは、コンピューティングにおける生産的な態度ではないことに完全に同意します。

私のポイントは、SciPyエコシステムが非常に人気があり、変更を管理するための単一のアプローチがすべての人に適しているわけではないということです。 それは、メソッドとその実装が特定の分野でどれだけ速く進化するか、実践者の技術的能力、彼らが依存する他のソフトウェア、彼らがコードに投資できるリソースなどに依存します。

現在のNumPyコアチームは、安定性よりも進歩（一部の分野では重要だが他の分野にはほとんど関係のない方向へ）に関心を持っています。 それは問題ありません。オープンソースの世界では、仕事をする人が何に取り組みたいかを決定します。 しかし、私の印象では、NumPyに依存する仕事をしている多くの人々が異なるニーズを持っていることに気づかず、開発チームに見捨てられたと感じ、SciPyからCやFortranなどのより伝統的で安定したテクノロジーに移行し始めています（そして、ある場合には、Matlabにさえ知っています）。

NumPyユーザーの何パーセントが現在の状況に十分に不満を持っているのか私にはわかりません。他の誰もがそうしているとは思いません。 ソフトウェアパッケージがインフラストラクチャになると、誰がそれに依存しているかを簡単に見積もることはできません。 知らない人も多く、NumPyに（直接的または間接的に）依存するコードの多くは公開されていないか、簡単に発見できません。

SciPyコミュニティのすべての人を幸せに保ちたいのであれば、多様なニーズに対処する方法を見つける必要があります。 私の意見では、最初のステップは、特定のインストールの変更率の制御を、開発者からエンドユーザーに近い人に移すことです。 それは、エンドユーザー自身、システム管理者、パッケージャー、またはその他の人である可能性があります。この質問に対する普遍的な答えはないと思います。 これが開発者に要求するのは適切なレベルの情報であり、それが私がこのスレッドを始めた理由です。 もちろん、バージョン番号は世界を救うことはできませんが、変更管理に対する分散型の責任を確立するための最初のステップと考えています。

最後に、私が自分のコードについて個人的な戦いをしていると信じている人もいるようです。 私の個人的な態度が私がここで擁護しているものではないことに驚かれるかもしれません。 私自身の変化率のスイートスポットは、私の分野で一般的なものとNumPyチームで普及していると思われるものの間のどこかにあります。 今日の私の仕事のほとんどは、Python3とNumPy> 1.10を使用しています。 MMTKは20歳で、今日はさまざまなことをしています。 特定のプロジェクトに必要なMMTKからコードを取り出して「最新のSciPy」に適合させることがよくありますが、それは元のコードを書いたからこそ自信を持ってできることです。

私は、自分で使用するのではなく、コミュニティへのサービスとして安定したMMTKを維持しています。これが、コードベースの大規模な変更を避けて、最小限の方法でメンテナンスを行っている理由です。 ソフトウェアとドメインコンピテント開発者の両方への資金提供を見つけるのは非常に難しいため、MMTKは常に1人のメンテナと臨時の貢献者プロジェクトであり続けています。 MMTKに依存するコードの多くは完全に保守されていないため、すべてのMMTKを「最新のSciPy」に移植しても効果があるかどうかさえわかりません。 しかし、それは、MMTKとはまったく関係のないコードでさえ、私の周りにあるほとんどのPythonコードに当てはまります。 それは、計算やコーディングではなく実験が注目されている研究領域の現実です。

@xoviat oldnumericのテストの数は途方もなく少ないです。 彼らがNumPy1.13で合格したという事実から、私はあまり結論を出さないでしょう。

あなたが見ているC拡張モジュールは文字通り20年前のものであり、Python1.4用に書かれています。 当時、これはPython-Cコンボの最も洗練された例のひとつであり、実際、Numeric（pre-NumPy）、さらにはCPython自体の初期の開発を形作りました。CObjects（pre-Capsules）は、ScientificPythonとMMTKのニーズに基づいて導入されました。 。

今日のAPIとサポートツールの方がはるかに優れていると最初に言いましたが、今後も改善されると思います。 でも、昔ながらのソフトウェアを使って研究したいという人もいて、存在する権利もあると思います。

@rgommersユーザーがバージョン番号を見ることさえできないというあなたの議論を無視していません。 それは、人々が私の周りで使用している環境には当てはまりません。 更新について決定する人々（必ずしもエンドユーザーではない）はそれを見ます。 彼らは週に一度「pipinstall--upgrade」を行うだけではありません。 彼らはこれを不注意な態度だとさえ考えるでしょう。

周りの人々が主にWindowsでAnacondaを使用している場合、それは私たちが非常に異なる環境で作業していることを確認するだけです。 多様性の時代において、私たちは、各コミュニティがそれに適したツールや慣習を採用する可能性があることに同意できることを願っています。

はい、NodeJSはもっと悪いです、私は同意します。 幸いなことに、私はそれを簡単に無視することができます。

このスレッドをフォローしているが、あえてチャイムを鳴らさない同僚から電子メールを受け取ったところです。優れた例えで：

「新しい顕微鏡を購入して、それを使ってより良い科学を行う機会を得たとき、私はそれが大好きです。しかし、誰かが私に相談せずに私の顕微鏡を一晩交換するのを見たくありません。」

それはすべて自分のツールを制御することです。

私は夜中にあなたの同僚の研究室に侵入して彼らのしびれをアップグレードすることは決してないことを約束します。 私はバラクラバさえ持っていません。

更新について決定する人々（必ずしもエンドユーザーではない）はそれを見ます。 彼らは週に一度「pipinstall--upgrade」を行うだけではありません。 彼らはこれを不注意な態度だとさえ考えるでしょう。

彼らがシステム管理者であり、さまざまなインストール方法の長所と短所を理解している場合は、Pythonの世界（および厳密なsemverを使用していない他の多くのソフトウェアプロジェクト）でのバージョン管理がどのように機能するかを実際に理解する（または教える）必要があります。

現在のNumPyコアチームは、安定性よりも進歩（一部の分野では重要だが他の分野にはほとんど関係のない方向へ）に関心を持っています。

申し訳ありませんが、これは、過去数年間にNumPyの開発をまったくフォローしていないか、非常に特殊なメガネを使用していることを示しています。 NumPyは、下位互換性について多くの懸念があるため、実際には貢献するのが非常に難しいプロジェクトです。 これが、新しいメンテナを引き付けるのに苦労している主な理由の1つです。

そして、ある場合には、Matlabにさえ

Matlabは、互換性を損なうことで有名でした。 Matlabを使用した共同プロジェクトで最初に行ったのは、ドキュメントに使用されていたMicrosoft Wordと同じように、全員が使用する必要のあるバージョンを指定することでした。 互換性を向上させるためにNumPyに正確に切り替えた人々を知っています。 Matlabには長所がありますが、互換性はその長所の1つではありませんでした。 おそらく物事は変わったのでしょうか？

ただし、互換性に役立つ可能性のある、今後できることがいくつかあると思います。 最初は、NEPの現在の議論に結びついています。 NumPyがより成熟した今、互換性に影響を与える変更が提案されている場合、特にNEPがより公開されて検索可能である場合は、NEPをより多く利用することをお勧めします。 第二に、それがあまり手間がかからない場合は、PyPIに古いNumPyバージョンのホイールを設置することを試みることができます。 仮想環境の使用は、再現性を実現するための現在の最良のアイデアのようであり、ダウンロードするホイールの選択肢を広げることがそれを助けるかもしれません。

第二に、それがあまり手間がかからない場合は、PyPIに古いNumPyバージョンのホイールを設置することを試みることができます。

@ matthew-brettの努力のおかげで、現在の状況では、Windowsホイールが1.10に戻り、MacOS1.7が欠落している場合を除く）、Linuxが1.6に戻っているようです。

MacOS / Linuxの状況はかなり合理的なようです。 もっと多くのWindowsリリースを埋め戻すことができると思いますか？ WindowsのOTOH pip installは、英雄的な努力なしでは機能していなかったので、これに多くの聴衆がいるかどうかはわかりません。 私たちはすでに2年の価値があり、それは時間とともに成長します。

また、前回古いホイールをアップロードしたときに、ワークフローでホイールがないと想定され、下位互換性が失われたため、誰かが私たちに腹を立てました:-)

その話を聞きたいです。

私はこれを本当によく知っているわけではありませんが、私たちは物事を改善しようと試みることができると思います（それが何を意味するのかよくわかりません！）、実際には、ゆっくりと前進する必要があり、おそらくいくつかのエラーを除いて、すべてのリリースはごく少数の人々のコードを破ることを意味しました。 私たちのマイナーリリースは「ほとんどすべての人が更新し、何も気付かずに更新できるようにする必要がある」という意味だと思います。率直に言って、それは本当だと思います。 （明らかに、整数の非推奨など、多くの人々に影響を与えたものがありますが、それらは間違った結果を生み出さず、長い間作成されていました）

率直に言って、どちらになるかはわかりませんが、メジャーバージョンをインクリメントするのに十分な大きさの変更があった可能性があることがわかります。 そして、はい、メジャーリリースに関しては、歴史的に勢いが失われている可能性があります。

いずれにせよ、私は（ほぼ）すべてのリリースがメジャーリリースであると言うのが好きだとは言えません。 いくつかの変更で人々を怒らせたかもしれないと思いますが、私はいくつかのかなり大規模な変更に参加し、理由を説明した後、それが正しいことであると聞いただけで、また私たちは待っていましたこれらの変更が有効になるまでの数年。

gccなどについてです。たとえば、コンパイル/ C ++についてはよくわかりませんが、gcc 4.8に悩まされていたため、C ++ 11の機能が原因で、フラグを正しく変更する方法を理解せざるを得なくなりました。期待されているので、これはあなたがnumpyについて受け取っているように見える電子メールと非常によく似た反応を引き起こすので、私はそれが大きく異なるかどうかはわかりません:)。

とにかく、ここではあまり議論したくありません。速すぎるのか、注意が足りないのかについてのフィードバックに感謝しますが、メジャーバージョンの変更が大いに役立つとは思えないことも認めなければなりません。それ。 個人的には、1.13と1.6はある意味で少なくとも1つのメジャーバージョンが離れていると思いますが、その間に単一のリリースはありません。それは多くのユーザーにとって大きな互換性の問題でした。
コード内のコメントを読んだことを覚えています：「Numpy2でこれをやろう」というのは、まったく壊れることを恐れているからです。そのアプローチでは、numpyがかなり行き詰まってしまうのではないかと心配しています。率直に言って、私はその一部であることを少し誇りに思っています。私には少なくとも、もっと活発な段階のように見えましたが、それは必要であり、私たちがさらに保守的であったならそれは困難だったでしょう。 （私が来る前に何が起こったのかあまり手がかりがないので、おそらく偏見があります:)）。

申し訳ありませんが、これは意味がないかもしれません（私たちはちょうどクリスマスパーティーをしました）。 semverの提案は理にかなっていますが、本当の解決策のようには感じられないことを認めなければなりません。 メジャーバージョンをより積極的にインクリメントしようとすることには同意できますが、基本的にすべてのリリースをメジャーリリースと呼ぶことにも同意しません。 場合によってはもっと保守的にしようとすることにも同意できますが、率直に言って、それらが何であるかはよくわかりません（どこかで互換性が損なわれる可能性があるかどうかは誰にもわからないため、ハングしているPRの数を数えてください;）、確かに良い部分です）？

そして、私が不満を読んだとしても、あなたが少しのバグや主張を持ってきたとしても、それが合理的に可能であるか、少なくとも1年以上それを遅らせるならば、私たちがすべての変更を元に戻すわけではありません。 それは、私たちが保守的なガバナンスモデルを選択した理由の一部だと思います…。

だから長い間せせらぎをした後：

• 「コードが壊れている人はほとんどいない」というのは、マイナーバージョンでは問題ないように思われますか？
• ゆっくり前進しなきゃいけないの？
• 最終的には問題が発生し、メジャーバージョンをインクリメントできる場合もあります。 おそらく、メジャーバージョンでFutureWarningタイプをさらに変更しようとすることさえあります。 （率直に言って、それが役立つとは思いませんが、試してみます）

最も重要なこと：私は欲求不満を知っていますが、私たちにとって本当の解決策はありますか？ メジャーバージョンを積極的にインクリメントすると、メールが少なくなると思いますか？

@xoviatは、古いバージョンのホイールをアップロードすることについて苦情を受けることについての話を求めていますか？ それは＃7570でした。

semverの私のお気に入りの定義（元の投稿へのリンクが見つからなくなった）：

• メジャー：意図的にユーザーコードを解読しました
• マイナー：誤ってユーザーコードを壊した
• パッチ：ユーザーの回避策を最後のマイナーリリースのバグに分解しました

これは少し生意気ですが、インポートするものにヒットすると思います。動作の_任意の_変更はどこかで一部のユーザーを壊すでしょう。 これは、APIサーフェスが大きいプロジェクトに特に当てはまります。

私の意見では、最初のステップは、特定のインストールの変更率の制御を、開発者からエンドユーザーに近い人に移すことです。

この会話に欠けているのは、古いバージョンのライブラリが常に（ソースからのpypiで）利用できることです。したがって、古いバージョンのpython / numpy / matplotlibを必要とするコードがある場合は、古いバージョンを使用してください。 ユーザースペース環境では、これを管理するのはそれほどひどくありません。

新しいバージョンのライブラリを使用する場合は、変更に対応するためのコストを支払う必要があります。 顕微鏡の例えを推し進めるには、顕微鏡の定期的なメンテナンスを行う必要があります。そうしないと、時間の経過とともに劣化します。 ソフトウェアも例外ではありません。

@njsmithそれはかなり面白いです。 IMO＃7570は、次のことを考えると有効な問題ではありません。
NumPyはmanylinuxホイール仕様に準拠していました。 一般的に、ホイール
時間が空いていると仮定して、古いバージョンの場合はアップロードする必要があります。 与えられた
その時間は無料ではありません、私たちは人々が車輪を作ることができることに単に注意することができます
NumPyの特定のバージョンが必要な場合。 にPRを提出する
numpy-wheelsリポジトリ。 か否か。

@xoviatつまり、彼らのシステムが壊れた場合、それは壊れました。 仕様を指すことができても、それは実際には変わりません。 一般に、これらの議論では、理論上の純度よりもエンドユーザーへの実際の影響に注意を払う必要があると思います。 しかし、この場合のOTOHは、問題を回避し、ホイールがすでにアップロードされており、私たちが知る限り、より多くの人々が恩恵を受けていることを考えると、ホイールを上げ続けることは正しい呼びかけだったと思います問題がある。 しかし、それは「後方の非互換性」がいかに微妙であり、一般的なルールを作成することがいかに難しいかを思い出させる興味深いものです。

@njsmith顕微鏡の例えでのあなたの役割は、顕微鏡のセールスマンが同僚のラボディレクターに近づき、ラボのすべての顕微鏡を最新のモデルに交換して、「厚さ1mmを超えるサンプルと互換性がない」という文を細字で隠すことです。契約の。 このため、ラボのディレクターは、それらの詳細を理解している人々と話し合う必要のある技術的なポイントがあることを理解することが非常に困難になります。

@rgommers NumPyを維持することは雑用であることを私は理解しています。実際、私が担当している場合、ほとんどの場合、その理由で変更を異なる方法で処理します。 現在のコードを最小限のメンテナンスモードにして、別の名前空間で大規模な再設計を開始し、バッファインターフェイスを介した相互運用性で新旧を無期限に共存させます。 はい、私はこれが多くの理由でささいな努力ではないことを知っています、しかし私はそれが蓄積された技術的負債の山から抜け出す唯一の方法だと思います。 再設計の主な目標は、保守性です。

一方で、私は確かに非常に特別な眼鏡を持っていることを認めますが、それはこの議論の他のすべての人に当てはまります。 私のメガネは、私の職場環境である「伝統的な科学計算」のメガネです。 ベースライン（デフォルトの期待値）は、更新によって意図的に何かが壊れることはないということです。 これは、標準化された言語（C、Fortran）だけでなく、インフラストラクチャライブラリ（BLAS、LAPACK、MPIなど）のポリシーでもあります。 それにもかかわらず、イノベーションは起こります（例：ATLAS）。 それが保守的だと思うなら、私の世界で保守的とはどういう意味かを説明しましょう。ほとんどのバグが確実にわかるように、2年以上経過していないバージョンをインストールしないでください。 これは、時間が非常に高く、そのために結果を確認することがほとんどできないスーパーコンピューターの一般的なポリシーです。

NumPyが私の世界のデフォルトの期待を採用すべきだと言っているのではないことに注意してください。 私はそれが違うことを明確に示すべきだと言っているだけです。

@seberg 「ほとんど誰もコードが壊れていない」は、マイナーバージョンでは理論的には問題ないようです。 しかし、ソフトウェアの一部がインフラストラクチャのステータスを取得すると（そして、私の意見では、NumPyはそのレベルにあります）、影響を受ける可能性のある開発者とユーザーの数を見積もることは不可能です。 その場合、基準は常に「私が考えることができる人はほとんど影響を受けない」になり、それは良いものではありません。

@tacaswell実際には、「非常に

率直に言って、「大規模な再開発」のアイデアは、はるかに多くの開発力を必要とし、まったく異なるタイプの混乱を引き起こす可能性があるため、現在ほとんど放棄されていると思います（最初の数年間はpy2とpy3を参照）。

同意しました。numpyはインフラストラクチャですが、メジャーバージョンをより速くバンプすることで、より多くの人のコードを壊しても問題がないかのように振る舞うのが好きではありません。 「ほとんど誰もコードが壊れない」リリースを実行するために最善を尽くすというタスクをあきらめるような気がします（おそらく「2、3のリリースの警告を見ていなければ」例外があります）、そして実際に決定を助けます更新の。

ですから、それが真実ではないかもしれないことを認めるべきかもしれませんが、そうでなければ、私たちがそれ以上壊れないことを確実にするための解決策を得たいと思います。 もちろん、あなたは解決策を提案しました（非常に保守的で、大規模なオーバーホールでnumpy 2を開始しました）が、この解決策が大規模な資金などなしでは実行できないことを認めたら、他に何ができますか？

または、はっきりさせておきます。必要に応じてより保守的になることを監視できる、numpy devをフォローできる人を知っているなら、少なくとも私はそれを感謝しています。 しかし、私は個人的に、将来の開発を可能にするために、numpyの暗いコーナーのいくつかを少なくともゆっくりと取り除くという私たちの進歩をあきらめることに感謝していません。 せいぜい、数年でNumPyが死んで交換されてしまい、最悪の場合、前に進むことができず、おそらく「交換」が発生することに不満を感じて、ダウンペースでダウンストリームになってしまいます。成熟していない場合は、事態を悪化させます。

別の名前空間の作成については、 @ sebergに同意する
このアイデアの背後にある全体的な仮定は、NumPyプロジェクトには無制限があるということです
すべての人に役立つライブラリを維持するための才能とリソース。
ただし、そうではありません。 開発者は完璧ではないので、通常は
初めて間違えます。 オリジナルの数値コードを書いている人
それが使用されるすべてのシナリオを予測することはできませんでした、そして彼らは
PyPyなどの代替実装の台頭を予測できませんでした。

APIの安定性は非常に重要だと思います。 NumPyも持っていると思います
一般的にそれを正しくしました。 問題の事実は、NumPyがすでに
推論するのは難しい（そして、最後の1オンスの
パフォーマンスは重要です）が、別の名前空間を作成すると、
コードを変更することのすべての影響を維持することは非常に困難です
あなたの頭。 NumPyがそうしたら、そうなる可能性が高いと思います。
開発者が理解していないため、バグが大幅に増える
一方のインターフェイスでもう一方のインターフェイスでコードを変更した場合の影響。

要約すると、私は人々の欲求不満を完全に理解しています。 しかし@njsmithとして
とはいえ、すべてのユーザーを満足させる問題の解決策はありません。
ほとんどの場合、ほとんどのユーザーを満足させるソリューションのみがあります。 そして
現実には、NumPyが少数のユーザーに蹂躙した場合（
蔑称的な方法で）他のすべてよりもAPIの安定性を要求した、
NUMFOCUSの資金は、金額が明確でないために枯渇する可能性があります
に使用された、そして私たちはどこにいるのでしょうか？ おそらく次のような状況で
MMTKは、状況と同じように、NumPyに依存できなくなりました。
Numericに依存しなくなりました。

現在のコードを最小限のメンテナンスモードにして、別の名前空間で大規模な再設計を開始し、バッファインターフェイスを介した相互運用性で新旧を無期限に共存させます。 はい、私はこれが多くの理由でささいな努力ではないことを知っています、しかし私はそれが蓄積された技術的負債の山から抜け出す唯一の方法だと思います。 再設計の主な目標は、保守性です。

私は実際にあなたに同意しますが、資金/ビジョンの大規模な注入なしでそれがどのように実現可能であるかはわかりません。 NumPyは膨大な量の作業を構成します。 たぶん@teoliphantと@skrahはそれをでしょう、しかしそれは困難な戦いになるでしょう。

私たちが今日持っているNumPyを考えると、私たちは合理的にできることと同じようにやっていると思います。

「はい」と答えた人のために、2番目の質問：これまでにこれを行ったnumpy以外のソフトウェアに名前を付けることができますか？

djangoは、セマンティックバージョニングを使用しないもう1つの注目すべきソフトウェアです。 それらは大幅な中断を示すために大きな変更を使用しますが、長期間の警告の後、.xの変更では非推奨になります。 NumPyのように多かれ少なかれ。

私は実際にあなたに同意します、

@shoyerは興味がないのですが、なぜですか？ ある時点で、それが新しいコードベースへの非常に苦痛なpy3kのような移行にならないのはどうしてですか？

これは、標準化された言語（C、Fortran）だけでなく、インフラストラクチャライブラリ（BLAS、LAPACK、MPIなど）のポリシーでもあります。 それにもかかわらず、イノベーションは起こります（例：ATLAS）。

LAPACK / ATLAS / OpenBLASのペースでのイノベーションは、NumPyが他の方法よりもはるかに早く無関係になるためのレシピです。

ほら、すべての回答から、このバージョン変更が発生しないことは明らかである必要があります。これは、最大7つのアクティブなコア開発者と主要なダウンストリームプロジェクトのいくつかの開発者の間のコンセンサスです。 絶対的な安定性が必要な場合は、システムに固定バージョンを数年間固定し、それについてシステム管理者に教育することをお勧めします。

ある時点で、それが新しいコードベースへの非常に苦痛なpy3kのような移行にならないのはどうしてですか？

大きな違いは、Python 3は（Pythonプログラムの場合）オール/ナッシングスイッチであるのに対し、異なるndarrayライブラリを簡単にまたは少なくとも組み合わせることができることです。 バッファインターフェイスは、コピーなしでデータをやり取りできることを意味します。 np.asarray()を使用して関数への入力を強制すると、操作しているライブラリが別のタイプの配列を返すようになっていることに気付かない場合があります。

これは、numeric / numarray / numpyの一部を繰り返すように聞こえます
経験、これもあまり快適ではありませんでした（バッファインターフェイスは
ヘルプが、そのような移行にはまだ手動コードが含まれると思います
変更、すべてが些細なことではありません）。 それも不可能になります
Scipyなどのライブラリがなしで「新しいアレイ」に「アップグレード」する場合
下位互換性を壊しているので、問題は上向きに泡立ちます
エコシステム、他の図書館に同様の決定をさせる
古い名前空間を放棄します。

全員がnp.asarrayで入力を強制した場合、 np.matrixは問題になりません:-)。

異なる配列ライブラリがduckタイプについて合意でき、バッファプロトコルで表現可能なdtypeに制限する場合、それは機能します。 しかし、書き換えの全体的なポイントが、配列オブジェクトに互換性のないインターフェイスの変更を加え、新しいdtypeを実装することである場合、...それを機能させる方法が本当にわかりません。 具体的な例：この種の書き換えで修正すべき明らかなことの1つndarray.dot 、高次元入力でのdef f(a, b): a.dot(b)するライブラリがそこにある場合、そのようなライブラリを作成すると、ライブラリが破損する可能性があります。 そのライブラリがnumpyと呼ばれるかどうかは実際には問題ではありません。

そして、それは、すべてを1つのビッグバンで書き直すという一般的な不可能性にさえ入る前であり、それを実行している間、開発者の注意を維持し、それを正しくするだけでなく、人々に移行するように説得できるほど良くすることです。ユーザーからの増分フィードバック。 dyndはここで有益な例だと思います。

@rgommers私が書いたことをもう一度読んでください：私は、NumPyがLAPACKのペースを採用することを提案しません。繰り返しません。 私は、それがそうではないような期待を持っている人々（すなわち、私の環境の人々の80％）に明確に信号を送ることを提案します。

@njsmith再設計の主な側面は、OOを放棄することだと思います。 多数の関数が機能する単一のデータ構造のコードを構造化するのは、良いアプローチではありません。 np.dot(a, b)と書くと、あなたが説明した問題はすぐに消えてしまいます。 namespace.dotの実装はいくつでも構いません。 各ライブラリは好きなものを使用でき、それでも相互運用できます。 メソッドの単一の名前空間を作成するのはOOであり、それが問題です。

はい、それはPythonの習慣の大きなブレークです。 そして、はい、その上に演算子を実装するのは難しいでしょう。 しかし、それは可能だと思いますし、努力する価値があると思います。

私が物事を壊すことに賛成できることを示すためだけに;-)

@rgommers私が書いたことをもう一度読んでください

という事は承知しています。 私の返信の2つの段落は直接関連していませんでした。混乱していた場合は、申し訳ありません。

私は、それがそうではないような期待を持っている人々（すなわち、私の環境の人々の80％）に明確に信号を送ることを提案します。

それは私が言っていたことです、コンセンサスはあなたの提案が拒否されるということのようです。 その80％に固定されたバージョンを要求し、それが必要な理由を説明する必要があります。

@khinsen OK、代わりに私の例は、可能であれば確実に行うインデックスの互換性のない変更であると偽ってください。 （ファンシーインデックスには、非常に紛らわしいコーナーケースがいくつかあります。）

@njsmithある意味で同じ問題。 インデックス作成はPythonのメソッド呼び出しであるため、再びOOになります。

補足：ファンシーインデックスは、明確な仕様さえ持っていない（そして決して持っていなかった）ので、私の意見では、NumPyの最大の設計ミスです。 整数引数の場合はnp.takeを実行し、ブール引数の場合はnp.repeatを実行します。 ブール値はPythonの整数のサブタイプであるため、0と1のみを含む引数のあいまいさが生じます。

実際には、このスレッドのトピックと関係があります。これは、開発の進行が速すぎる場合に発生する設計ミスの一種だからです。

SciPyコースでは、ファンシーインデックスについて、使用しないように指示するためだけに説明しています。 np.takeとnp.repeatあり、これらは完全に機能し、問題は発生しません。 また、メソッドではなく関数として使用する場合は、OOの問題もありません。 ブール値で使用したときに名前が意図を示唆していないためにnp.repeatが嫌いな場合は、エイリアスselect = np.repeat導入してください。 ここでも、OOによって何かが不必要に困難になりました。

プレーンインデックスはそのような問題の影響を受けないことにも注意してください。 これは、考えられるすべての状況下でほぼすべての人が期待することを実行するため、メソッドで実装できます。

私の観点からの厄介な問題は算術です。 np.add(a, b)ではなく、配列の追加のためにa+bを記述したいのですが、特に結果のdtypeに関して、正確にa+bが何をすべきかについての普遍的な合意はありません。 。 これはNumeric / numarray分割の中心的な問題の1つであり、NumPyに新しいスカラー型が導入されました。これらは、不快な驚きをかなりの割合で引き起こします。 この問題は解決できると思いますが、GitHubの問題に関する議論については補足しません。

@rgommers 「その80％に固定されたバージョンを要求する」ことが可能であったなら、私はずっと前にそれをしていました。 「その80％」はあなたが話すことができる組織化されたコミュニティではありません。 背景文化を共有しているが、お互いに交流していない人はたくさんいます。 あなたの提案は、「WindowsユーザーにLinuxへの切り替えを要求する」（またはその逆）に少し似ています。

これは、NumPyがインフラストラクチャソフトウェアであることを主張することによって私が主張しようとしているポイントです。 多くの人にとって、ソフトウェアのインストールを構成するのは、数百のレゴブロックのうちの1つにすぎません。 彼らは特にそれを気にしません、それはただそこにいて「働く」必要があります。

これをあまり狂わせたくないのですが、np.repeatとbool配列で何を指しているのかわかりません

@ eric-wieserを0回繰り返し、配列から1回削除しても、そのまま残ります。 インデックスを作成する代わりにこれを教えることに同意しませんが、何でも（最近では最悪の奇妙さがなくなったので、ほとんどの場合、ブール値はintではあり

サイドポイント、これはもうどこにも行かないので:)。 私は実際、numpyの内容をゆっくりと修正することで、将来のある時点でnumpyをより交換しやすくすることを望んでいます。

あなたの提案は、「WindowsユーザーにLinuxへの切り替えを要求する」（またはその逆）に少し似ています。

うーん、技術的に有能な人に（私は願っていますが...）現実世界のバージョン番号が実際にどのように機能するかを学ぶように頼むことは、

これは、NumPyがインフラストラクチャソフトウェアであることを主張することによって私が主張しようとしているポイントです。

そしておそらく、この切り替えを行うとしたら、インフラストラクチャの次のビットであるSciPyに移行しますか？ いつインフラストラクチャでなくなるのですか？ そして、なぜNumPyやその他のインフラストラクチャは、Python自体やその他の科学的なPythonエコシステム全体とはまったく異なるバージョン管理スキームを必要とするのでしょうか。

その80％」はあなたが話すことができる組織化されたコミュニティではありません。

あなたが使用しているスーパーコンピューターの管理者は、本当にお互いに話し合うべきですか？ これらのいくつかのシステムですべての更新ソフトウェアを走り回って、決して話をしない大勢の人がいることはあり得ません。 世界中のすべてのシステム管理者の80％を教育する必要があるという意味ではなく、必要なものだけを教育する必要があります。

@sebergリストと配列は異なるデータ型であり、共通のプロパティとしてインデックスを共有するだけであると宣言することは、採用する有効な観点です。 また、特定のNumPyスカラーの存在を説明しやすくします。 しかし、私はこの観点を取り入れたNumPyのプレゼンテーションを見たことがありません。

@rgommers

あなたが使用しているスーパーコンピューターの管理者は、本当にお互いに話し合うべきですか？

いいえ。彼らはお互いの存在についてさえ知りません。 彼らはさまざまな場所のさまざまな組織で働いており、その唯一の共通点は、少数のユーザーを共有することです。

世界中のすべてのシステム管理者の80％を教育する必要があるという意味ではなく、必要なものだけを教育する必要があります。

これは私のことではありません-私は自分自身のために完全にうまく機能する解決策を持っています：私は常にPythonとすべてのライブラリをソースからホームディレクトリにインストールします。

これは、私が協力している人々と私に助けを求めている人々です（たとえば、彼らが過去に私のPythonコースの1つに参加したため）。 彼らには、自分のPythonインストールを管理し、他の誰か（管理者または経験豊富な同僚）に任せる技術的能力がありません。

実世界のバージョン番号が実際にどのように機能するかを学ぶ

私が考えている人々の共有された背景文化では、現実の世界は実際にはセマンティックバージョニングまたは近似のように機能します。

私が考えている人々の共有された背景文化では、現実の世界は実際にはセマンティックバージョニングまたは近似のように機能します。

それは、限られた数のライブラリを使用しているためです。ほとんどの場合、LAPACK＆coのように動きが遅くなります。 @njsmithが指摘したように、ソフトウェアの大部分は、セマンティックバージョニングを使用していないため、バージョン番号が低くなっています。

@rgommers 「少数」とは言いませんが、ほとんどの場合、動きの遅いライブラリを使用します。

@njsmithが指摘したように、ソフトウェアの大部分は、セマンティックバージョニングを使用していないため、バージョン番号が低くなっています。

私の経験ではありません。 しかし、「大多数」はおそらくあなたと私の両方にとって「私が知っているもののほとんど」を意味し、SciPyエコシステムの外では、あなたが使用するパッケージと私が使用するパッケージの間におそらくほとんど重複がありません。

そしておそらく、この切り替えを行うとしたら、インフラストラクチャの次のビットであるSciPyに移行しますか？ いつインフラストラクチャでなくなるのですか？

私は確かにSciPyとSciPyエコシステムのその他すべての基本原則が同じ原則を採用することを望んでいますが、個人的には、NumPy以外の場所でこれを議論するための努力を投資しません。他のライブラリ、そしてはるかに基本的なもの。 NumPy配列は、多くの科学ソフトウェアの中心的なデータ構造ですが、SciPyは、特定のアプリケーションが小さなサブセットを使用する関数の膨大なコレクションにすぎません。

SciPyは、1.0に達したばかりであるため、おそらく意図的ではありませんが、事実上セマンティックバージョニングを使用していることにも注意してください。

そして、なぜNumPyやその他のインフラストラクチャは、Python自体やその他の科学的なPythonエコシステム全体とはまったく異なるバージョン管理スキームを必要とするのでしょうか。

SciPyエコシステム全体は、実際に同じアプローチを使用する必要があります。これは、（私が見ているように）科学計算で支配的なアプローチです。 これは、習慣が異なる他のドメインのPythonおよびPythonライブラリには適用されません。 たとえば、Web開発は、科学計算よりもはるかに保守的ではありません。 また、ほとんどの場合、さまざまなユーザーを気遣うさまざまな人々によって行われます。 Python言語が唯一の連絡先になります。

NumPy配列は、多くの科学ソフトウェアの中心的なデータ構造ですが、SciPyは、特定のアプリケーションが小さなサブセットを使用する関数の膨大なコレクションにすぎません。

そして、中央のデータ構造は安定しています。 特定のリリースでの互換性のない変更の大部分はコーナーケースであり、ほとんどの場合ndarrayの動作ではありません。 たとえば、 https： //github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility-notesを参照して

SciPyは、1.0に達したばかりであるため、おそらく意図的ではありませんが、事実上セマンティックバージョニングを使用していることにも注意してください。

SciPyは、NumPyとまったく同じバージョン管理スキームと非推奨/削除ポリシーを使用します。 長期間0.xにいることは、semverを意味するものではありません。

（私が見ているように）科学計算で支配的なものです

SciPyエコシステムの従来の比較は、MatlabやRなどとの比較です。Rに関する情報は見つかりませんが、3.xであり、大きく進化しているため、おそらくsemverではありません。 Matlab：間違いなくsemverではありません。

RE：派手な索引付け。 確かに、これは専用の機能を使用することができます。 これは、TensorFlowで行われたことです。たとえば、 tf.gather 、 tf.gather_nd 、 tf.scatter_nd 、 tf.boolean_maskなどを使用します。結果は、より冗長になります。 []オーバーロードしますが、確かにより透過的です。

役立つもう1つの機能は、型注釈です。これは、Python2から3への移行の難しさに部分的に動機付けられた機能です。

これが簡単だと言っているのではありません。 私の考えでは、コミュニティへの影響はもっと大きな問題です。 これは確かに、実装してからSciPyのようなプロジェクトに下流にプッシュするのに多くのエネルギーを必要とします。

@khinsen私は一週間ずっと議論を続けてきました、そして私はそれに対するあなたの見解をテストするための実際的なテスト問題があると思います。 これは、これまでの少し抽象的な議論ではなく、あなたの視点がそのような対立をどのように処理するかを確認するのに良い項目かもしれません。

現在、Apple Accelerateフレームワークのおかげで、必要なLAPACKの最小バージョンは3.1.ishで、これは10年以上前のものです。 そして現在、LAPACKは3.8.0です。 その間に、彼らはかなりの数のルーチンを破棄し（非推奨および/または削除）、多くのバグを修正し、最も重要なことに、商用ソフトウェアとPython科学ソフトウェアの間のギャップを埋めるために必要な新しいルーチンを導入しました。 最終結果はここに要約さ@rgommersやその他の人たちを常に悩ませてきました😃そして、彼らがあなたがおそらく不本意ながらここに描写したような人々であったかどうかを保証できます人。 代わりに、彼らはAccelerateのサポートをやめるのがそれほど簡単ではない理由を辛抱強く説明してきました。

現在、新しいバージョンに対する明白なニーズがあります。 それは議論ではなく、その部分を安全にスキップすることができます。 NumPyとSciPyのユーザーのかなりの部分がこれから恩恵を受けるでしょう。 しかし、あなたがすでに提示した議論のために、単にそれを落とすことはできません。 これをどのように解決しますか？

私はこれを卑劣な方法で尋ねているわけではありませんが、すべての開発者が同じように考えているように見えるので（そして私は彼らに同意すると言わなければなりません）、おそらくあなたの見た目は新鮮なアイデアを与えることができます。 そのようなことが起こるたびに、Accelerateを維持し、新しいNumPy / SciPyパッケージを作成する必要がありますか？ イノベーションのためにサポートをやめるとしたら、ここに行くための最善の方法は何だと思いますか？

現在、Apple Accelerateフレームワークのおかげで、必要なLAPACKの最小バージョンは3.1.ishです。

@mhvk 、これは

@xoviat ：その問題についてこの議論をしましょう

@ilayn具体的で建設的な方向にこの議論を

主な共通点：さまざまなニーズを持つさまざまなユーザー/コミュニティがあります。 Accelerateが必要な人もいれば、LAPACKの新機能が必要な人もいます。 どちらにも、特定の優先順位には十分な理由があります。 Accelerateと新しいLAPACK機能の両方が必要な人もいるかもしれませんが、これは私にはわかりません。

Fortran / Cの世界では、ソフトウェアスタックが浅いため、このような問題はありません。 追加の中間体なしで、Fortran、LAPACK、およびアプリケーションコードがあります。 何が起こるかというと、各アプリケーションコードはその優先順位に応じてLAPACKの特定のバージョンを選択します。 コンピューティングセンターは通常、複数のLAPACKバージョンを並列に保持し、それぞれが独自のディレクトリにあります。選択は、アプリケーションコードのMakefile変更することによって行われます。

SciPyエコシステムに引き継ぐことができ、引き継ぐべき教訓は、ソフトウェアバージョンの選択はソフトウェア開発者の仕事ではなく、アプリケーション固有のソフトウェアバンドルを組み立てる人々の仕事であるということです。 私たちの世界では、Anaconda、Debian、およびその他のソフトウェア配布に取り組んでいる人々だけでなく、さまざまなレベルのシステムマネージャーや、適切な能力と動機を持つエンドユーザーもいます。

したがって、SciPy / LAPACKのジレンマに対する私の提案は、Accelerateを使用して今日のSciPyを維持することですが、最小限のメンテナンスモード（おそらく別の人に引き継がれる）にします。 Accelerateが必要な人は、「SciPy2017」を選択して幸せになれます。 彼らは新しいLAPACK機能を取得しませんが、おそらくそれはそれらのほとんどで問題ありません。 開発は新しい名前空間（ scipy2 、 scipy2018など）で続行され、最新のLAPACKに切り替わります。 技術的に可能な場合は、これら2つの（および将来の）バリアントの並列インストールを許可します（SciPyでは可能であると思います）。 そうしないと、両方が必要な人は複数の環境（conda、venv、またはNixまたはGuixを介したシステム全体の環境）を使用する必要があります。 この2番目のシナリオでも、互換性のない変更を行うたびに名前空間を変更することを強くお勧めします。これにより、あらゆるレベルのPythonコードの読者が、コードが記述されたSciPyバージョンを確実に理解できるようになります。

全体的な考え方は、開発者が新しいものを提案する（そしてその開発に集中する）が、一般的な意味で「より良い」ものとして、または普遍的な代替品として宣伝しないということです。 特定のタスクに適したソフトウェアバージョンの組み合わせを選択することは彼らの仕事ではなく、他の誰かの仕事です。

開発と組み立ては独立して、さまざまな人々によって行われるという一般的な考え方は、今日のメガパッケージをさまざまな速度で進行できる小さなユニットに分割する必要があることも示唆しています。 今日、NumPyに小さなLAPACKインターフェースとf2pyようなツールが含まれている理由はありません。 SciPyの場合、一貫性を示す共通の名前空間と共通の開発ポリシーを持つことは理にかなっているかもしれませんが、サブパッケージは独立して配布することもできます。 メガパッケージアプローチは、20年前に素晴らしかったPythonの「バッテリー込み」のモットーにまでさかのぼります。 今日のユーザーベースはそれにはあまりにも多様であり、ソフトウェアパッケージングは​​一般的に別個の活動として認識されてきました。 バッテリーを含めることは、アナコンダの仕事になるはずです。

このようなアプローチを採用する上での主な障害は、DebianやFedoraなどの従来のLinuxディストリビューションと「マシンごとに1つのPythonインストール」アプローチです。 妥当な労力で複数のシステム全体の仮想環境に切り替えることができると思いますが、私はこれについてあまり考えていません。 私にとって、ソフトウェアパッケージングの未来は、condaやGuixなどの環境ベースのシステムです。

あなたがこれまでに出したすべての前置詞がこれらのステップのいずれかとどのように互換性があるのか​​わかりません

• 次の写真の狂気を再現しました
  
  数えたところ、Windowsマシンに27個のコピーがあります。 ここで、これに10を掛けます（リリースはここでより頻繁に行われます）。2を掛けます（NumPyとSciPyのリリースサイクルは独立しているため）。 2025年には、各ライブラリのコピーを15個、LAPACKを10個、f2pyを5個依存関係として簡単に作成できます。 両方のパッケージに含まれる数十人のメンテナンスの負担は言うまでもなく、これは単に機能しません。 （C ++は関係ありません、何かの標準ライブラリを挿入してください）。 商用コード開発者にWinを依頼し、これはとても良い考えだと伝えてください。 私はその交換で何が続くかについて責任を負いません。
• 次に、パッケージの粒度を上げ、さまざまなパッケージバージョンを使用してすべてを独自に実行します。 f2pyはあるバージョンで何かを壊したので、SciPyは次のバージョンでビルドを停止しますが、それでも以前のバージョンのNumPyに依存しています。 したがって、一部の全体論的エンティティは、それらを無料でまとめる必要があります。
• 次に、アナコンダ（または他のエンティティ）を、Accelerateと同じように大きな依存関係にある会社にしました。 または単に「他の誰か」がたくさんいるでしょう。
• 次に、ほとんどのユーザーベースを、仮想環境を含む（私自身も含めて）本当に望まないワークフローに動員しました。
• 次に、Linuxオペレーティングシステムを変更しました（つまり、彼らのメーリングリストを読んだだけです。楽しいです）。

多分あなたは少し逸脱しました。

（これは自由な議論になっているので、先に進んで飛び込みます）。

Accelerateのサポートを維持することの問題は、新しいLAPACKAPIがないことではありません。 それが問題だった場合は、新しいLAPACKシムを出荷して完了できます。 問題は、特定のシナリオで誤った結果を返す基本的な関数があることです。 独自のBLAS関数を作成する以外に、これを回避する方法はありません。 その場合は、OpenBLASまたはMKLが必要になる可能性があります。

@xoviatこれらはすべてhttps://github.com/scipy/scipy/pull/6051で説明されてい

@ilaynはい、私が言っている点についてはすでに知っていると確信しています。 しかし、コメントは@khinsenに対するものでした。 彼は私たちが実際にAccelerateのサポートを維持できるという印象を受けていると思います。

Pythonエコシステムの機能（または制限）は、名前マングリングの恐ろしいハックなしでライブラリの1つのバージョンを取得することであると主張することができます。 これはコアPythonで発生します。 _lib_という名前のライブラリと同じ目的が、APIの違いを持っている_lib_ 2がある理由です。 鉱石のPythonでさえこのように機能します。 誰かがそれをリッピングしてPyPiに置くことなく、両方が最新のPythonで技術的に使用可能であっても、バージョン間で標準ライブラリを混合することはおそらく不可能です。 これにはStackOverflowの質問がたくさんありますが、すべて同じ結論です。

@ilayn何らかの理由で、マシン上のすべてのバージョンのすべての可能な組み合わせをすべて使用したい場合は、そうです、それは混乱です。 しかし、なぜあなたはそれが欲しいのですか？ アプリケーションシナリオに実際に必要な組み合わせに制限すると、それは少なくなると思います。 例として、私は自分のマシンにちょうど2つのPython環境を保持しています。1つは20年前のコードを実行するためのPython 2 + NumPy 1.8.2で、もう1つは他のすべてのために約2年前の最先端を表しています（ 2年前に設定したのですが、その後アップグレードする理由が見当たらないためです）。

粒度については、私の提案ではおそらくはっきりしていませんでした。 私が提唱しているのは、開発ではなく、パッケージングの粒度を高めることです。 たとえば、f2pyとSciPyの開発は緊密に連携して継続されると思います。 f2py-2018とSciPy-2018は連携する必要があります。 それは、それらが単一のエンティティとしてパックされる必要があるという意味ではありません。 目標は、ソフトウェア配布マネージャーが作業を行うためのより多くの自由を提供することです。

Anacondaやその他のディストリビューションを依存関係にしたくはありません。 それは「他人の豊富さ」のようなものですが、それらを組み立てるのは大変な作業であることを考えると、ディストリビューションの数が「豊富さ」に増えるとは思いません。

「ユーザーベース」がどのようなワークフローを望んでいるのかわかりません。 さまざまな要件を持つさまざまなユーザーベースがたくさんあります。 個人的には複数の環境に行きますが、マシンごとに1つの環境を必要とする重要なユーザーベースがある場合は、一部のディストリビューションがそれを処理します。 しかし、仮想環境が発明されたのには理由があり、実際の問題を解決します。 NixやGuixのようなシステムレベルのディストリビューションは、それらを別のレベルに引き上げます。 彼らがいなくなるとは思わない。

ところで、私は実際に1つのLinuxディストリビューション（Guix）のメーリングリストをフォローしています。 それほど楽しいことではありませんが、現実的なうなり声がたくさんあります。 これをやっている人がいて嬉しいです。

@xoviat 「サポートを加速し続ける」ことは提案しませんでした。 博物館の古いリリースとしてではなく、特定のユーザーグループにとって関心のあるバリアントとしてSciPyバリアント（ほぼ現在のもの）を維持することをお勧めします：Accelerateを使用することが問題を解決するよりも重要であるAccelerateは他の人のために作成します。 「最初に加速する」人々は、彼らの選択した結果とともに生きなければなりません。 いくつかの問題は彼らのために決して修正されないでしょう。 それはおそらく彼らにとっては問題ありません（「既知のバグは未知のバグよりも優れています」）ので、なぜそれらを別のものに強制するのですか？

ラベル付けとコミュニケーションがすべてです。 私は、「より高い」バージョン番号で示されるように、新しいバージョンが「より良い」という、直線的な進歩の道をたどるソフトウェアの理想的なイメージから離れたいと思っています。 このイメージを、より現実的だと思うイメージに置き換えたいと思います。ソフトウェアリリース間に明確な順序関係はありません。 長期にわたる一貫性のある開発者コミュニティによって作成されたものには一時的な順序がありますが、それは特定のアプリケーションの品質や適合性については何も意味しません。

理想化されたイメージが正しければ、フォークは表示されず、仮想環境もありません。 VersionClimberなどのプロジェクトもありません。

私が提案しているのは、ソフトウェア開発者はこの現実を否定するのではなく、受け入れるべきだということです。 彼らは多様性の世界のために製品を開発する（そして何よりもパッケージとラベルを付ける）必要があります。

@khinsen線形代数関数の誤った結果で問題がない場合は、サポートを加速し続けることができます（他の人への注意：これを行う方法を知っています）。 しかし、主な問題は、これを望んでいるのはあなただけかもしれないということです。 そして、そうでなくても、誰かが加速の問題でSciPyを非難するとどうなりますか？ 誰かが自分のケーキを持ってそれも食べたいと思ったらどうなりますか？ 私はそれが起こっているのを見ることができます。

@xoviatいいえ、線形代数関数の結果が正しくないので問題ありません。 しかし、影響を受ける機能をまったく必要としないSciPyユーザーはたくさんいると思います。 あなたが参照したスレッドで、誰かがAccelerateが検出されたときに影響を受ける関数を削除/非アクティブ化することを提案しました。これは良い解決策だと思います（注：これを実装するために必要な労力を判断できません）。

ある意味で、これはメガパッケージの問題の一部です。 よりきめ細かいディストリビューションを使用すると、開発レベルとディストリビューションアセンブリレベルの両方で機能するものを簡単に選択できます。 ドメイン固有およびプラットフォーム固有のSciPyディストリビューションを構成するディストリビューションアセンブラーを想像することもできます。このディストリビューションでは、たとえばHPCコンテキストで使用するために、さまざまなサブパッケージがさまざまなLAPACKバージョンを使用します。

しかし、影響を受ける機能をまったく必要としないSciPyユーザーはたくさんいると思います。

この声明には最小限の証拠があり、私は実際には反対に賭けます。 これらの関数は広く使用されていますが、特定のシナリオでのみ失敗します。 言い換えれば、あなたの結果はおそらく正しいですが、そうではないかもしれません。 はい、これはおそらく、OSXを使用している場合に現在インストールしているSciPyに当てはまります。 はい、これを修正する必要があります。

別のブランチを維持する限り、維持するために特定のブランチへの書き込みアクセスを許可することに反対する人はいないと思います。 しかし、これはオープンソースソフトウェアであり、人々は自分のやりたいことに取り組んでいます。 多くの人がそのブランチを維持することに興味があるのではないかと私は懐疑的です。

実際、anaconda SciPyはMKLでコンパイルされていると思うので、その場合は影響を受けません。 しかし、なぜあなたはサポートを加速することを気にするのでしょうか？

@xoviatここには大きな誤解があるようです。 私はこの特定の問題に個人的な利害関係はまったくありません。 SciPyの線形代数ルーチンは使用していません。

あなたはSciPyの問題に関するスレッドを指摘し、そのような状況をどのように処理するかを尋ねました。 このスレッドは、Accelerateのサポートを単純に削除することに抵抗があることを明確に示しています。この変更から、このような変更の影響を受ける重要なユーザーグループが存在すると推測しました。 そのユーザーグループが存在しない場合、問題はどこにありますか？ SciPyがAccelerateのサポートをまだ終了していないのはなぜですか？

@xoviat別のブランチを維持することは誰にとっても簡単です。 同じGitHubリポジトリでホストする必要はありません。 言い換えれば、ブランチは問題ではありません。 問題は、別々のSciPyバージョンの並列存在をユーザー（およびディストリビューションアセンブラー）に対して透過的にするための名前空間です。

今日、「import scipy」というコードが表示された場合、どの範囲のSciPyバージョンが機能するかがわかりません（つまり、ある程度テストされています）。 最良の場合、「SciPy> = 0.8」などのREADMEがあります。 この習慣は、「より高い」バージョンは常に「より良い」ものであり、何も劣化（中断、減速など）しないという仮定に基づいています。 そして、その仮定はまったく間違っています。

一方、コードに「import scipy2017 as scipy」と記載されている場合は、以前のバージョンまたはそれ以降のバージョンで使用すると、悪い驚きにつながる可能性があることはすべての読者にとって明らかです。 また、古いSciPyバージョンが（事実上、メンテナンス不足のために）消えた場合、そのようなコードは、信頼性の低い動作を続けるのではなく、エラーメッセージで失敗します。

これは私がこのスレッドで作ろうとしている1つのポイントです。 異なるバージョンの共存は現実です。 高いほど良いという考えは夢です。 複数のバージョンの宇宙を認め、誤解を防ぐために全員のコミュニケーションを調整することによって、現実的になり、現実の世界に向けて自分自身を整理しましょう。

まあ、わからない…警告に関しては、特定のバージョンのインポートは警告ではなく、別のバージョンを使用することは禁止されています。説明したように問題を抱えているユーザーは、あえてコードを変更しないからです。 インストール/実行時に特定のnumpyバージョンを除くすべてのバージョンでテストされていないという警告を出力すると、警告が表示されますか？

そのタイプの追加パッケージを作成することは可能だと思います。 私はまた、それがただ異なるタイプの地獄を作り出すことを期待しています。 多くのことが生き残るかもしれませんが、たとえば、2つのバージョンを混在させると、型チェックは機能しないか、機能しないため、基本的に、試してみるまで機能するかどうかはわかりません（誰もこれをテストしません！）。
また、2つのバージョンを混在させることを提案していない限り、scipy2017ソリューションは事態を悪化させるだけだと思います。 動的/ランタイム仮想環境の選択のようなものが必要になるようです（Pythonレベルでインポートする前にpin_import_version("1.6<numpy<1.10", level="raise")に）。

特定のインポートは、大きな禁止変更（py2 / py3のようなもの）がある場合に意味があり、その「主要な」行がどこに、またはどのような時間スケールであるかについて、さまざまな意見があることはすでにわかりました。

後方互換性NEP＃11596が提出されましたが、これを閉じることはできますか？

後方互換性NEP＃11596が提出されましたが、これを閉じることはできますか？

はい、これを閉じることができます。 そのNEP（拒否された代替手段としてsemverについて明示的に言及している）とは別に、ここでのコア開発者のコ​​ンセンサスは、semverに変更したくないということです。 したがって、wontfixとして閉じます。

皆さん、議論してくれてありがとう。