Numpy: 请求:使用语义版本控制

创建于 2017-12-04  ·  88评论  ·  资料来源: numpy/numpy

语义版本控制是软件开发,分发和部署中广泛使用的约定。 尽管就其适用性进行了长期讨论(Google知道在哪里可以找到它),但今天它仍然是默认设置。 有意识地决定使用语义版本控制的项目倾向于选择发布编号方案,以使其立即变得清晰明了,例如使用日期而不是版本。

NumPy是广泛使用的软件的稀有示例之一,该软件使用的版本编号方案看起来像语义版本控制,但实际上并非如此,因为通常会引入破坏性更改,而仅对次要版本号进行更改。 这种做法在软件开发人员,软件用户和软件发行经理之间产生了错误的期望。

这一点尤为重要,因为NumPy是与操作系统或编译器相同的基础架构软件。 大多数使用NumPy的人(作为开发人员或软件用户)通过Anaconda或Debian等软件发行版间接获取和更新NumPy。 通常由系统管理员来决定更新。 启动更新的人员和可能受到破坏更改影响的人员都不会遵循NumPy邮件列表,并且大多数人甚至都不会阅读发行说明。

因此,我建议NumPy在将来的版本中采用语义版本控制约定。 如果有充分的理由不采用该约定,则NumPy应该采用不能被误认为是语义版本控制的发行标签方案。

15 - Discussion

最有用的评论

当前的NumPy核心团队更关心进展(对于某些领域来说是重要的方向,但在很大程度上与其他领域无关),而不是稳定性。

很抱歉,但这只表明您在过去几年中根本没有关注NumPy的开发,或者没有一套非常特殊的眼镜。 NumPy实际上是一个非常困难的项目,因为对向后兼容性存在很多担忧。 这是我们很难吸引新的维护人员的主要原因之一。

所有88条评论

是否可以将numpy视为使用语义版本控制,但使用前导1

请注意,几乎每个核心科学Python项目都执行NumPy的工作:在几个发行版本之后删除不推荐使用的代码,除非这非常具有破坏性,并且只会使主要版本的主要版本号增加。

不知道您是要建议更改弃用策略,还是不确定我们现在应该使用的是14.0.0版本而不是1.14.09。

后者:到目前为止,NumPy的版本应大致为14。 但是我建议仅在将来的版本中采用此约定。

顺便说一句:NumPy的前身Numeric确实使用了语义版本控制,并在大约十年的时间内升级到了版本24。 我不知道为什么在过渡到NumPy时更改了它。

我的印象是,绝大多数Python项目都不使用语义版本控制。 例如,Python本身不使用语义版本控制。 (我也不知道任何使用semver的主流操作系统或编译器-您有什么想法吗?)我同意semver的支持者在营销方面做得很好,导致许多开发人员认为这是一个很好的方法。这个想法,但是AFAICT对于任何大于左键盘的项目在现实世界中都是行不通的,而且我强烈反对这样一种想法,即混帐人员现在“拥有”传统的MAJOR.MINOR.MICRO格式,其他所有人都必须切换到某种格式其他。

您能否举例说明“不能误认为语义版本控制的发布标签方案”的含义? 使用名称而不是数字? 您引用了基于日期的版本控制,但是我看到的最常见的方案是Twisted和PyOpenSSL所使用的方案,目前分别为17.9.0和17.5.0。 在我看来,这些看起来像是完全合理的semver版本。

您能否详细说明这将给用户带来什么好处? 在这个假想的未来中,就像现在一样,每个版本都会有一些与大多数用户无关的重大更改。 每隔几个月就会增加主要数字,我们将传达什么有用的信息? “这可能会打扰某人,但可能不会打扰您”? 鉴于历史上不可避免的错误,即其中很大一部分会破坏至少一个人的代码,我们是否还应该在bugfix版本上增加主要版本? 您能否举例说明实际上感到困惑的“软件开发人员,软件用户和软件发行经理”?

请注意,邮件列表是进行此讨论的更合适的场所,可能在实际进行任何更改之前我们可能必须在此进行讨论,但是此处的注释对于了解您想要什么样的问题很有用。在讨论中解决。

@njsmith看来,我们唯一不同的事实是语义版本控制是否是当今的默认假设。 这要求对其(或不是默认)社区的定义有一个更清晰的定义。 我关心的软件管理级别是发行管理和系统管理,这是人们决定哪种版本最适合其上下文的地方。

非正式询问使我得出结论,语义版本控制是默认的,它包括与科学计算设备的管理员交谈。 我也设想
一种更经验的方法(列出最近安装的Debian上的软件包,并随机选择其中一些软件包来研究其版本控制方法),但是事实证明这非常困难,因为很少有项目明确说明是否使用语义版本控制。

一位系统管理员的评论特别让我感到震惊:他说,出于决定安装哪个版本的目的,除了语义版本控制之外的任何约定都没有用。 系统管理员既不能详细研究每个软件包(他们缺乏时间和能力),也不能咨询所有用户(他们太多)。 他们必须采用统一的策略,并且这往往基于语义版本控制的假设。 例如,一个计算集群的管理员告诉我,在应用具有主要版本号更改的更新之前,他与一些他认识的“高级用户”进行了核对。

至于实际上有些困惑的人,特别是关于科学Python用户的例子,我有很多人:工作中的同事,我在会议上遇到的人,通过电子邮件寻求建议的人,我班的学生。 通常以“我知道您是Python专家,可以帮助我解决问题?”开头。 原来,这个问题是一个脚本可以在一台计算机上运行,​​但不能在另一台计算机上运行。 这些人中的大多数根本不考虑依赖关系问题,但实际上有几个人比较了两个安装的版本号,仅发现“微小差异”。

正如@ eric-wieser和@rgommers指出的那样,我的请求几乎

一位系统管理员的评论特别让我感到震惊:他说,出于决定安装哪个版本的目的,除了语义版本控制之外的任何约定都没有用。

不幸的是,语义版本控制对此也没有用:-(.。我不是故意要夸张或夸张;我完全明白这是一个真正的问题,但是仅仅因为问题是真实的并不意味着它有解决方案。从根本上讲,您不能把“我应该升级此软件吗?”这个问题简化为简单的机械检查。这是一个幻想。发布。

系统管理员既不能详细研究每个软件包(他们缺乏时间和能力),也不能咨询所有用户(他们太多)。 他们必须采用统一的策略,并且这往往基于语义版本控制的假设。 例如,一个计算集群的管理员告诉我,在应用具有主要版本号更改的更新之前,他与一些他认识的“高级用户”进行了核对。

我喜欢这部分:-)。 我怀疑我们会同意semver的理念,但是讨论不同版本控制方案的具体效果以及我们认为最理想的结果要容易得多。

我认为semver的概念与该策略没有多大关系-您与之交谈的系统管理员实际上检查每个项目是否使用semver吗? 正如您所说,大多数项目都没有,甚至很难说出是哪个项目。 而且该策略与sysadmin早在semver尚未存在之前就一直在使用。 我认为该政策的一个更好的特征是:“遵循项目建议中有关升级的谨慎程度”,以及古老的传统,即主要版本是“大”而次要版本是“小”。

NumPy项目的建议是系统管理员应升级到新功能版本,因此我从此轶事中得出的结论是,我们当前的编号方案可以准确传达我们想要的功能,并且切换到semver不会...

@njsmith好吧,让我们从哲学转向实际:在软件开发人员,系统维护人员和软件用户之间的通信中,软件版本号的作用是什么?

同样,我们在这里似乎意见分歧很大。 对于您来说,是开发人员向系统维护人员和用户提供说明,并使用版本号传达其说明。 对我来说,每个玩家都应根据自己的标准做出决定,版本号应作为最粗略的事实交流方式。

鉴于NumPy没有安全隐患,所以我不明白NumPy项目应该如何以及为什么应该提出通用建议。 人和机构有不同的需求。 这就是为什么我们同时拥有ArchLinux和CentOS,并且具有不同的更新策略。

@khinsen oldnumeric软件包仍然可以完美运行,人们可以通过以下方式安装它:

pip install oldnumeric

也许这可能是您建议的“稳定numpy”,其中numpy的接口仅限于Python / Cython,并且从未更改过。 当然,使用oldnumeric编写代码非常不可思议,但是您不能同时使用两种方式。

@xoviat是的,但这是另一个问题。 我的意思不是软件保留,而是软件管理中不同参与者之间的通信。

问题:作为系统管理员(甚至只是在您的个人计算机上),您是否希望软件包将完整的API层从1.8版降到1.9版?

对于那些回答“是”的人,第二个问题:除了numpy之外,您还能命名其他软件吗?

顺便说一句,我可以向您保证,很多人为此感到痛苦,因为我收到许多邮件,问我为什么MMTK从一天到第二天都停止工作。 所有这些人都对软件安装进行了例行更新,而没有预料到任何严重的后果。

但是丢弃oldnumeric并不是最近NumPy历史上最糟糕的事件。 该荣誉是更改某些操作(例如diagonal的复制/视图语义的。 根据NumPy版本(次要版本号更改!)返回不同结果的代码是一场噩梦。

顺便说一句,因为几乎没有人知道这个故事: pip install oldnumeric从两天前开始工作,因为@xoviat准备了这个附加软件包并将其放在PyPI上。 非常感谢!

您是否希望软件包将完整的API层从1.8版降到1.9版?

您指的是哪一层?

您能命名除numpy之外的其他软件吗?

SciPy放弃了weavemaxentropy软件包, pandas定期中断主要功能。 我敢肯定,还有很多更突出的例子。 编辑:例如Python本身,请参见https://docs.python.org/3/whatsnew/3.6.html#removed

顺便说一句,我可以向您保证,很多人为此感到痛苦,因为我收到许多邮件,问我为什么MMTK从一天到第二天都停止工作。 所有这些人都对软件安装进行了例行更新,而没有预料到任何严重的后果。

这项更改大约需要10年的时间,而且不可能有不同的版本控制方案在此有所作为。

删除不赞成使用的功能是折断一小部分(较旧的)代码与保持代码库易于维护之间的权衡。 总体而言,如果我们犯了错误,那么我们很可能会保守一些。 作为一个也不得不处理使用numpy的古老大型企业代码库的人,我感到很痛苦,但是您在争论某种绝对不是解决方案的东西(通常没有完整的解决方案;请教用户关于固定版本和检查弃用警告等事情是我们能做的最好的事情)。

您指的是哪一层?

我认为是数值/数字数组支持

@rgommers对不起,我应该说“ SciPy生态系统之外的另一个例子”。

另外,我也没有抱怨放弃对oldnumeric 。 我抱怨这样做没有更改主要版本号。

那会有什么不同? 如果不阅读发行说明,人们就会犹豫不决地进行更新。 每个使用(但不开发)Python代码的人都将其视为谨慎的标志。

不要忘记,SciPy生态系统拥有大量低调的用户,他们并不积极关注开发。 Python和NumPy是与lsgcc具有相同性质的基础结构项目。 而且通常还不止这些:他们使用的某些软件恰巧是用Python编写的,而且恰好依赖于NumPy,而一旦中断,它们就会完全丢失。

@rgommers对不起,我应该说“ SciPy生态系统之外的另一个例子”。

刚刚编辑了我的回复,并带有指向SciPy生态系统之外的Python发行说明的链接。

那会有什么不同? 如果不阅读发行说明,人们就会犹豫不决地进行更新。 每个使用(但不开发)Python代码的人都将其视为谨慎的标志。

事实并非如此。 如果我们使用的不是11.2、1.13、1.14等,而是12.0、13.0、14.0,则用户会习惯于此,并且将使用与以前相同的升级策略。 绝大多数人不会突然变得更加保守。

不要忘记,SciPy生态系统拥有大量低调的用户,他们并不积极关注开发。 Python和NumPy是与ls和gcc具有相同性质的基础结构项。 而且通常还不止这些:他们使用的某些软件恰巧是用Python编写的,而且恰好依赖于NumPy,而一旦中断,它们就会完全丢失。

都是正确的,而且不是所有版本号都可以神奇修复的。 如果他们运行pip install --upgrade numpy ,他们必须知道他们在做什么(而且这甚至都没有显示版本号)。 如果是他们的打包系统,那么他们会看到该软件的问题,即没有合适的测试套件(或未运行)会中断。

现在更改版本控制方案的其他缺点:

  • 我们将在不更改维护政策的情况下对版本进行更改,这会造成混乱,而不会有帮助
  • 我们现在基本上遵循了Python的领导,并且与整个生态系统的其余部分一样。 这是一件好事
  • 也许最重要的是:我们将失去发出重大变更信号的能力。 我们将使用2.x的类型,例如可能破坏ABI的版本。

我的基准参考不是Python,而是典型的软件安装。 正如我所说,对于许多(也许是大多数)用户,NumPy是诸如gnu-coreutils或gcc之类的基础架构。 他们没有特别在SciPy生态系统的上下文中解释版本号。

我对装有约300个软件包的Debian 9系统进行了快速检查。 其中85%的版本号以整数开头,后跟点。 最常见的整数前缀是1(30%),2(26%),0(14%)和3(13%)。 如果NumPy采用符合共同期望的版本编号方案(即语义版本或近似),则它肯定会脱颖而出,并应谨慎对待。

还请注意,Debian安装的软件中唯一对我不利的更新是SciPy生态系统,唯一的例外是Emacs更新,该更新带来了org-mode的更改,该更改破坏了自制的org-mode扩展。 因此,总体上较低的版本号前缀似乎表明最广泛使用的软件比NumPy和其朋友要稳定得多。

整个SciPy生态系统的一致性确实很重要,但是我更希望整个生态系统采用符合外界期望的版本控制方案。 我只是从NumPy开始,因为我将其视为最基本的部分。 它比其他任何东西都更加重要。

最后,我认为函数语义的变化比ABI的变化重要得多。 前者可能导致数百名用户的调试恶梦,并使程序多年来产生无法检测到的错误结果。 后者导致错误消息,清楚地表明需要修复某些问题。

根据这些标准,NumPy甚至没有跟随Python的发展,因为我知道在Python语言中唯一的语义变化是从2变为3。

最后,我认为函数语义的变化比ABI的变化重要得多。 前者可能导致数百名用户的调试恶梦,并使程序多年来产生无法检测到的错误结果。 后者导致错误消息,清楚地表明需要修复某些问题。

我们真的很努力地做到这一点。 删除某些功能时可能会发生明显的破损,而不会默默更改数值结果。 这是我们从对角线视角变化中学到的一件事-这是事后看来的错误。

它肯定会脱颖而出,并应谨慎对待。

我仍然不同意。 即使在Debian上,对于我们的用户群来说,绝对也不是“典型的软件安装”(这在Windows上就像Anaconda一样)。 您似乎也忽略了我上面的论点,即用户甚至无法正常查看版本号(既没有使用pip install --upgrade也没有使用软件包管理器)。

另外,您可能会遇到其他一切都不会中断的经历,这是因为您使用的是OS实用程序和GUI程序之类的东西,而不是其他大型依赖项链。 例如,整个JavaScript / NodeJS生态系统可能比Python生态系统更脆弱。

顺便说一句,我可以向您保证,很多人为此感到痛苦,因为我收到很多邮件,问我为什么MMTK从一天到第二天都停止工作

这是这里微妙之处的一个很好的例子。 据我所知,MMTK和您的其他项目是唯一仍然受删除数字/数字数组兼容性代码影响的项目。 您估计您有多少用户? 100? 1000? NumPy有数百万,所以也许0.1%的用户受到了此删除的影响? 这绝对不是零,并且它很小并不意味着这并不重要–我希望我们能够以各种方式永远支持100%的用户。 而且我了解到,这对您来说尤其痛苦,因为它收到了100%用户的投诉。

但是,如果我们为此改变主要版本号,则意味着对99.9%的用户,我们只是哭了。 这是一个误报。 OTOH对于那0.1%的用户来说非常重要。 尽管我们尽了最大努力,但在微型发行版中,我们还是打破了0.1%以上的用户的情况并不少见。 那么我们该怎么办?

根本不可能通过版本号的钝器传达这些细微差别。 每个人都希望有一种快速的方法,可以说出升级是否会破坏其代码,这有充分的理由。 Semver之所以受欢迎是因为它承诺会做到这一点。 流行的原因与人们认为流行饮食可以治愈癌症的原因相同。 我希望semver也能履行其诺言。 但是事实并非如此,如果我们想成为优秀的工程师,就需要应对现实的复杂性。

我看不到NumPy项目应该如何以及为什么应该提出普遍建议。 人和机构有不同的需求。

我们给出通用建议,因为我们只有1个版本号,因此根据定义,我们对它所做的任何操作都是通用建议。 那不是我们可以控制的。

该荣誉是更改某些操作(例如diagonal的复制/视图语义的。

IIRC从字面上看,我们还没有收到任何人说这违反了他们的密码。 (也许是一个人?)我并不是说这意味着没有人受到影响,显然,抱怨改变的人通常只占受影响者的一小部分,但是如果您将抱怨作为对现实的粗略理解,世界影响力,那么我认为这不会进入前50名。

顺便说一句,我很确定,如果您通过深入的历史进行搜索,您会发现比这更令人震惊的变化:-)。

还请注意,Debian安装的软件中唯一对我不利的更新是SciPy生态系统,唯一的例外是Emacs更新,该更新带来了org-mode的更改,该更改破坏了自制的org-mode扩展。

相对于NumPy与Debian,我认为这更能说明您如何使用NumPy与Debian。 我爱Debian,我已经使用了近20年,但我无法数出它坏了多少次。 就在上周,新的gnome出现了一个破坏了我的跟踪点。 (这两个问题现在都已修复,但是仍然是。)我还要指出,Debian的emacs设置为可以通过未加密/不安全的通道下载并运行代码已有多年了,这是因为对启用安全检查的向后兼容性问题。 我不认为gcc发行版不会破坏少数人,仅仅是因为人们做诸如使用-Werror类的事情,然后在警告行为上进行细微更改(这可能取决于细微之处)优化过程之间的相互作用等)成为重大变化。

因此,总体上较低的版本号前缀似乎表明最广泛使用的软件比NumPy和其朋友要稳定得多。

总体而言,较低的版本号前缀是因为使用最广泛的软件不使用semver。

最后,我认为函数语义的变化比ABI的变化重要得多。 前者可能导致数百名用户的调试恶梦,并使程序多年来产生无法检测到的错误结果。 后者导致错误消息,清楚地表明需要修复某些问题。

是的,这就是为什么我们对此类变化非常警惕。

这里的观点有些脱节:您似乎认为我们总是无时无刻不在改变事情,不在乎向后兼容性,等等。 我了解它反映了您的经验。 但是我们的经验是,我们会非常注意此类更改,我想说的是,当我与用户交谈时,有5%的人表示您的观点,约95%的人认为numpy在稳定性方面做得很好,还是说它做得太好了,应该更愿意破坏事物。 也许您可以放心,即使我们让您失望,我们也会让最后一组人失望:-)。

除了Emacs更新外

好吧,离开话题,这确实是稳定性的另一面的例子。 由于Stallman对变更的抵制,Emacs多年来一直是静态的,这导致出现了xEmacs分支。 我自己走的路是Emacs-> xEmacs,-> Vim;)过早的化石也是为什么我那天停止使用Debian的原因。 对于某些事情,根本不需要甚至根本不需要进行更改,并且我希望有人在藏在壁橱中的旧硬件上运行BSD的旧版本。 但是我不希望有很多这样的地方。

对于当前的问题,我认为在版本控制方案中进行更改不会真正产生任何影响。 更有效率的途径可能是解决现代化问题。 @khinsen您是否看到接受主要项目更新的方式? 如果是这样,我认为我们应该探索可以帮助您的方式。

我正在尝试更新以下项目
https://github.com/ScientificPython。 它需要更新Python代码
使用了旧的C API(我的意思是旧的;一些函数,例如Py_PROTO是
从2000年开始)。 公关当然是受欢迎的,但我不确定是否有人
想花时间在那上面。

我认为他提出的更大的问题是,“许多
项目”(我不知道它们到底在哪里,因为所有项目
我已经看到了对Python 3)的支持,它也需要更新; 如何
确定哪些项目分配了NumPy开发人员时间? 还有我
不要以为他的核心主张是无效的:SciPy可以从
它可以简单地复制并粘贴旧的fortran项目(例如
fftpack),几乎没有修改。 如果这些是写在上面
“ fortran 2”和新的编译器仅编译“ fortan 3”,
是重大问题。

也就是说,这些问题并不是NumPy的错。 尽管他有什么
说,在安装了NumPy 1.13的情况下,oldnumeric仍通过了所有测试,
表示NumPy不是此处的罪魁祸首。 由于oldnumeric API是
从字面上看已有十多年的历史(也许已经接近二十年了!),现在仍然
适用于最新的NumPy,我认为NumPy API可能很稳定
足够。

@charris我完全同意您的观点,即“永不改变任何事情”在计算中不是一种有生产力的态度。

我的观点是,SciPy生态系统已经变得非常流行,以至于没有任何一种管理变更的方法能适合所有人。 它取决于方法和其实现在给定领域中的发展速度,实践者的技术能力,他们所依赖的其他软件,他们可以投资于代码的资源等。

当前的NumPy核心团队更关心进展(对于某些领域来说是重要的方向,但在很大程度上与其他领域无关),而不是稳定性。 很好-在开源世界中,从事这项工作的人可以决定要从事的工作。 但是,我的印象是,他们没有意识到很多依赖NumPy工作的人有不同的需求,被开发团队抛弃,并开始从SciPy转向更传统和稳定的技术,例如C和Fortran(甚至在Matlab中我也知道)。

我不知道有多少百分比的NumPy用户对当前的状况感到不满意,而且我认为没有其他人对此感到满意。 一旦软件包成为基础架构,您就无法轻易估计谁依赖它。 许多人甚至没有意识到这一点,并且许多依赖于NumPy的代码(直接或间接)不是公开的和/或不容易发现的。

如果我们想让SciPy社区中的每个人都开心,我们需要找到一种方法来满足多样化的需求。 我认为第一步是将对特定安装的更改率的控制权从开发人员转移到更接近最终用户的人员。 那可能是最终用户自己,系统管理员,打包人员或其他任何人,我也不认为这个问题有一个普遍的答案。 开发人员所需要的是正确级别的信息,这就是我启动此线程的原因。 当然,版本号不能拯救世界,但我认为它们是建立变更管理的分布式责任的第一步。

最后,你们中的某些人似乎相信我正在为自己的代码而战。 我的个人态度不是我在这里捍卫的态度,这可能会让您感到惊讶。 我自己对变化率的最佳解决方案介于我所在领域的常见情况和NumPy团队中普遍见到的情况之间。 我今天的大部分工作都使用Python 3和NumPy> 1.10。 MMTK今年20岁,今天我做很多事情。 通常,我会从MMTK中获取我为特定项目所需的代码,并将其改编为“现代SciPy”,但这是我可以放心地做的,因为我编写了原始代码。

我一直在为社区提供稳定的MMTK服务,而不是供我自己使用,这解释了为什么我一直以最小的方式进行维护,避免了代码库的大规模更改。 很难找到软件和领域胜任的开发人员的资金,因此MMTK始终是一个由单个维护者加偶尔提供者的项目。 我什至不确定将所有MMTK移植到“现代SciPy”对任何人都有好处,因为依赖于MMTK的许多代码是完全不需要维护的。 但是,那对我周围的大多数Python代码都是正确的,甚至是与MMTK完全无关的代码。 这是研究领域的现实,其中重点是实验,而不是计算和编码。

@xoviat oldnumeric的测试数量非常少。 我不会从NumPy 1.13通过的事实中得出很多结论。

您一直在看的C扩展模块已经有20年的历史了,并且是为Python 1.4编写的。 那时,它是Python-C组合最复杂的示例之一,并且实际上影响了Numeric(pre-NumPy)甚至CPython本身的早期开发:根据ScientificPython和MMTK的需求引入了CObject(Capsule)。 。

我首先要说的是,当今的API和支持工具要好得多,并且我希望它们将来还会有所改善。 但是,有些人只是想使用软件进行研究,而不管它是多么过时,而且我认为他们也有权生存。

@rgommers我不会忽略您的论点,即用户甚至看不到版本号。 对于我看到人们在我周围使用的环境,这根本不是事实。 决定更新的人(不一定总是最终用户)会看到它。 他们不只是每周一次“ pip install --upgrade”。 他们甚至会认为这是一种粗心的态度。

如果周围的人主要在Windows下使用Anaconda,那仅表明我们在不同的环境中工作。 在多元化的时代,我希望我们可以同意,每个社区都可以采用适用于它的工具和惯例。

是的,我同意,NodeJS更糟。 幸运的是,我可以轻松地忽略它。

刚收到一位来自同事的电子邮件,该电子邮件遵循此主题,但不敢插队。

“当我有机会购买一台新显微镜并用它做更好的科学时,我会喜欢它。但是我不希望看到一夜之间有人更换我的显微镜而不咨询我。”

一切都取决于对工具的控制。

我保证我不会在半夜闯入您同事的实验室并升级他们的麻木。 我什至没有巴拉克拉瓦

决定更新的人(不一定总是最终用户)会看到它。 他们不只是每周一次“ pip install --upgrade”。 他们甚至会认为这是一种粗心的态度。

如果他们是系统管理员,并且了解各种安装方法的优缺点,那么他们真的应该也了解(或受教)Python世界中的版本控制(以及许多其他也没有使用严格权限的软件项目)如何工作。

当前的NumPy核心团队更关心进展(对于某些领域来说是重要的方向,但在很大程度上与其他领域无关),而不是稳定性。

很抱歉,但这只表明您在过去几年中根本没有关注NumPy的开发,或者没有一套非常特殊的眼镜。 NumPy实际上是一个非常困难的项目,因为对向后兼容性存在很多担忧。 这是我们很难吸引新的维护人员的主要原因之一。

在一种情况下,我什至对Matlab

Matlab因破坏兼容性而臭名昭著。 使用Matlab进行的合作项目所做的第一件事是指定每个人都必须使用的版本,如果用于文档,则与Microsoft Word相同。 我知道人们改用NumPy就是为了提高兼容性。 Matlab有其优点,但兼容性不是/不是优点之一。 也许情况已经变了?

但是,我认为我们可以做一些事情,可能有助于兼容性。 首先是与当前NEP的讨论有关。 现在,NumPy更加成熟了,当提议影响兼容性的更改时,尤其是在NEP更加公开且可搜索的情况下,更多地使用NEP可能是一个好主意。 其次,如果工作量不大,我们可以尝试在PyPI上为较旧的NumPy版本安装轮子。 虚拟环境的使用似乎是当前获得重现性最好的想法,并且有更多可供选择的下载轮子可能对此有所帮助。

其次,如果工作量不大,我们可以尝试在PyPI上为较旧的NumPy版本安装轮子。

感谢@ matthew-brett的努力,当前的状态似乎是Windows轮子回到1.10 ,MacOS回到1.5缺少1.7 ),Linux回到1.6

MacOS / Linux的情况似乎很合理。 我想我们可以回填更多Windows版本吗? Windows上的OTOH pip install以前从来没有经过英勇的努力才能工作,因此我不确定会有这么多的听众。 我们已经有2年的价值,并且随着时间的推移将会增长。

另外,上一次我们上传旧的车轮时,有人对我们感到愤怒,因为他们的工作流程认为没有车轮,并且向后兼容:-)

很想听听那个故事。

并不是我真的很了解这些东西,但是我想我们可以尝试改进一些东西(尽管我不太确定那是什么意思!),事实是,我们需要慢慢前进,除了所有发行版可能存在的一些错误之外意味着要破坏很少的人的代码。 我认为我们的次要发行版本意味着“几乎所有人都应该进行更新,并且能够在不注意任何内容的情况下进行更新”,并且坦率地说,这是事实。 (很明显,有一些事情影响了很多人,例如整数折旧,但是它们不会产生错误的结果并且制造时间很长)

我可以看到,可能会有一些大的变化,足以保证增加主要版本,尽管坦率地说,不确定是哪个版本。 是的,关于主要发行版,也许历史上失去了动力。

无论如何,我也不能说我(几乎)说每个发行版都是主要发行版。 我知道我们可能会因某些变更而惹恼了人们,但是我参与了一些相当广泛的变更,每次在解释了原因之后,我只听说这是正确的做法,而且我们也等待着这些更改生效之前的几年。

至于gcc等。例如,我对编译/ C ++并不了解,gcc 4.8令我烦恼,因此由于某些C ++ 11功能或其他原因,我开始强迫我弄清楚如何正确更改标志。因此,这可能会对您收到的有关numpy的电子邮件产生非常相似的反应,所以我不确定它是否有很大不同:)。

无论如何,我不想在这里讨论太多,感谢您对我们是否太快或不够谨慎的反馈,但是我不得不承认,我也不太认同更改主要版本会在很大程度上帮助那。 我个人认为1.13和1.6在某种意义上至少是一个主要版本,但是在这两个版本之间我没有一个可以指出的地方:对许多用户而言,这是一个重大的兼容性中断。
我记得读过代码中的注释:“让我们在Numpy 2中做到这一点”,正是因为担心所有中断,我担心numpy会停滞不前,坦率地说,我为成为其中一员而感到自豪至少对我而言,这似乎是一个更加活跃的阶段,这是需要的,如果我们更加保守,那将是困难的。 (我可能有偏见,因为我不太了解来之前发生了什么事:))。

抱歉,也许这没有任何意义(我们刚刚举行了圣诞晚会)。 合理的建议是有道理的,但是我不得不承认这并不是真正的解决方案。 我可以同意尝试更积极地增加主要版本,但是我也不同意将每个发行版都称为主要发行版。 我也可以同意在某些情况下要更加保守一些,但是坦率地说,我不确定这些是什么(只需计算挂起的PR的数量,因为没有人确定它是否会破坏某处的兼容性;),我敢肯定是一个很好的部分)?

即使我读过抱怨,如果您带来一些bug和坚持,那也不是说我们不会撤消所有更改,如果有可能的话,或者至少将其推迟一年或更长时间。 我会说这是为什么我们选择保守的治理模型的一部分。

因此,经过漫长的胡言乱语:

  • 对于次要版本,“几乎没有代码被破坏”似乎可以吗?
  • 我们要慢慢前进吗?
  • 事情最终会破裂,也许我们有时可以增加主要版本。 甚至尝试在主要版本中进行一些FutureWarning类型更改。 (坦率地说,我不相信这会有所帮助,但我愿意尝试)

最重要的是:我知道无奈,但是我们有真正的解决方案吗? 您是否认为如果我们积极增加主要版本,您会收到较少的电子邮件?

@xoviat您是否想询问有关上传旧版本车轮的投诉的故事? 那是#7570。

我最喜欢的semver定义(无法再找到原始帖子的链接):

  • 少校:我们故意破坏了用户代码
  • 小调:我们无意中破坏了用户代码
  • 补丁:我们打破了用户对最后一个次要发行版错误的解决方法

有点厚脸皮,但我认为碰到一件重要的事情是,行为上的任何改变都会破坏某个地方的用户。 对于具有较大API界面的项目尤其如此。

我认为第一步是将对特定安装的更改率的控制权从开发人员转移到更接近最终用户的人员。

我认为此对话中缺少的一点是,总是可以使用旧版本的库(从源上的pypi可用),因此,如果您的代码需要旧版本的python / numpy / matplotlib,则请使用旧版本。 用户空间环境使这一点难以管理。

如果要使用新版本的库,则必须支付跟上更改的费用。 要继续使用显微镜,您必须对显微镜进行例行维护,否则它会随着时间的流逝而退化。 软件也不例外。

@njsmith这很有趣。 鉴于以下原因,IMO#7570不是有效的问题
NumPy符合manylinux wheel规范。 通常,车轮
假设有空闲时间,则应上传较早版本的视频。 给定
时间不是免费的,我们可以简单地指出人们可以制造轮子
如果需要NumPy的特定版本; 向PR提交PR
numpy-wheels存储库。 或不。

@xoviat我的意思是,如果他们的系统崩溃了,那就崩溃了; 能够指向规范并不能真正改变它。 总的来说,我认为在这些讨论中,我们应该更多地关注对最终用户的实际影响,而不是理论上的纯度。 但是在这种情况下,OTOH我认为这是正确的选择,考虑到他们已经解决了这个问题,车轮已经被上传,据我们所知,有很多人受益于有问题。 但是,这很有趣地提醒我们,“向后不兼容”有多么微妙,以及制定通用规则有多困难。

@njsmith在显微镜类比中,您的角色是一位显微镜销售员,他与我的同事的实验室主任联系,提议用他的最新型号替换所有实验室的显微镜,并在句子中隐藏“与大于1mm的样品不兼容”的句子合同。 这使得实验室主管很难理解需要与了解这些细节的人员讨论一个技术要点。

@rgommers我确实了解维护NumPy是一件繁琐的事情,实际上,如果我负责的话,主要是出于这个原因,我会以不同的方式处理更改。 我将当前代码置于最小维护模式下,并开始在不同名称空间中进行重大重新设计,从而使新旧版本通过缓冲区接口无限期地共存,并具有互操作性。 是的,由于很多原因,我知道这并不是一件容易的事,但我认为这是摆脱累积的技术债务的唯一途径。 重新设计的主要目标是可维护性。

另一方面,我当然承认有一套非常特殊的眼镜,但这对本次讨论中的其他所有人都是如此。 我的眼镜是“传统科学计算”的眼镜,这是我的工作环境。 基线(默认期望)是更新永远不会故意破坏任何内容。 这是标准化语言(C,Fortran)的政策,也是基础结构库(BLAS,LAPACK,MPI等)的政策。 尽管如此,创新仍在发生(例如ATLAS)。 如果您认为这是保守的,那么让我描述一下保守世界在我的世界中的含义:切勿安装任何版本至少两年的版本,以确保已知大多数错误。 这是超级计算机的通用策略,因为超级计算机的时间非常昂贵,因此很难检查其结果。

请注意,我并不是说NumPy应该采用我的世界的默认期望。 我只是说这应该清楚地表明它与众不同。

@seberg “几乎没有人破坏了代码”对于次要版本在理论上似乎还不错。 但是,一旦某个软件获得基础架构状态(我认为NumPy处于该级别),就无法估计可能会影响多少开发人员和用户。 这样的标准总是变成“几乎没有人能影响我”,但这不是一个好标准。

@tacaswell,我认为“故意”和“偶然”之间的区别在实践中非常重要。 它影响着每个人对改变的态度。 只看生活的其他方面。 如果区别不重要,我们可以从英语中删除“小心”一词。

好吧,坦率地说,我认为“主要的重新开发”想法现在已经被放弃了,因为它需要更多的开发能力,然后还可能产生完全不同类型的混乱(头几年见py2和py3)?

同意,numpy是基础结构,但我不喜欢仅仅通过破坏更多的人的代码就可以解决/通过更快地碰撞主要版本来达到目的。 感觉更像是放弃了尽我们最大的努力来完成“几乎没有一个代码被破坏”版本的任务(也许带有“除非您没有观看过几个版本的警告”异常),然后实际上可以帮助做出决定更新。

因此,有时候我们可能应该承认这可能不是真的,但是否则,我宁愿获得解决方案以确保我们不会做得更多。 当然,您提供了一个解决方案(非常保守,并且开始进行大修的numpy 2),但是一旦我们承认没有大量资金就无法解决该问题,我们还能做什么?

还是让我明确一点:如果您知道有能力跟随numpy开发人员并且在必要时会注意保持保守,那么您至少知道我对此表示赞赏。 但是我个人不欣赏放弃我们的进展,至少要慢慢摆脱numpy中一些较黑暗的角落,以便将来发展。 充其量,我们将在几年内最终死掉NumPy并替换掉它,最糟糕的是,我们最终将被赶超而下游却因无法前进而感到沮丧,甚至可能出现“替代品”。如果不那么成熟,只会使事情变得更糟。

我必须同意@seberg有关创建其他命名空间的意见。 的
这个想法背后的全部假设是NumPy项目具有无限的
人才和资源来维护适合所有人的图书馆。
但是,事实并非如此。 开发人员并不完美,所以他们通常
第一次弄错。 编写原始数字代码的人
无法预测将要使用的所有方案,并且它们
无法预测其他实现的兴起,例如PyPy。

我认为API的稳定性非常重要。 我也认为NumPy有
通常来说是正确的。 事实是NumPy已经
很难推理(应该这样,因为最后一盎司
性能很重要),但是创建其他名称空间会使它
要保持更改代码的所有含义非常困难
你的头。 我认为,如果NumPy这样做,很有可能
由于开发人员不了解该错误,因此会出现更多错误
在一个接口的另一个接口上更改代码的后果。

总而言之,我完全理解人们的无奈。 但是作为@njsmith
说,没有解决方案可以满足每个用户。
只有大多数时间都能满足大多数用户的解决方案。 和
现实情况是,如果NumPy迎合了少数用户的需求(这并不意味着
以贬义的方式)要求API在所有其他方面都保持稳定,
NUMFOCUS资金可能枯竭,因为目前尚不清楚这笔钱是什么
被用来,然后我们会在哪里? 可能是在
MMTK不再可以依赖NumPy,就像它可以
不再依赖于数字。

我将当前代码置于最小维护模式下,并开始在不同名称空间中进行重大重新设计,从而使新旧版本通过缓冲区接口无限期地共存,并具有互操作性。 是的,由于很多原因,我知道这并不是一件容易的事,但我认为这是摆脱累积的技术债务的唯一途径。 重新设计的主要目标是可维护性。

我确实同意您的观点,但是如果不投入大量资金/愿景,我看不出这是如何可行的。 NumPy构成了巨大的工作量。 也许@teoliphant@skrah一马当先,但是这将是一场艰苦的战斗。

考虑到我们今天拥有的NumPy,我认为我们正在尽力而为。

对于那些回答“是”的人,第二个问题:除了numpy之外,您还能命名其他软件吗?

django是另一个不使用语义版本控制的著名软件。 他们使用重大更改来指示实质性的中断,但是在长时间的警告之后,不赞成使用.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不会是问题:-)。

如果不同的数组库可以就鸭子类型达成共识,并且我们将缓冲区协议表示为dtypes,那么它就可以工作。 但是,如果重写的全部目的是对数组对象进行不兼容的接口更改并实现新的dtype,则……我真的不知道如何使其工作。 具体示例:这种重写中要解决的一个明显问题是高维输入上的ndarray.dot行为。 但是,如果那里有一个执行def f(a, b): a.dot(b)的库,那么创建这样的库可能会破坏它。 该库是否被称为numpy并不重要。

而且这甚至还没有进入彻底重写所有内容的普遍可能性,在这样做的同时保持了开发人员的关注,不仅做到了正确,而且做得更好,它可以说服人们迁移-所有这些都没有用户的增量反馈。 我认为dynd是一个有启发性的例子。

@rgommers请重新阅读我写的:我不知道,重复,建议NumPy的应采取LAPACK的步伐。 我建议,它向那些有这种期望的人(即我环境中80%的人)清楚地发出信号。

@njsmith我认为重新设计的一个主要方面就是放弃OO。 这不是为具有大量功能的单一数据结构构造代码的好方法。 写下np.dot(a, b) ,您描述的问题立即消失。 您可以选择任意数量的namespace.dot 。 每个库都可以使用自己喜欢的库,并且仍然可以互操作。 是OO为方法创建了单个名称空间,这是一个问题。

是的,这是Python习惯的重大突破。 是的,在此之上实现运算符将非常棘手。 但是我认为可以做到,而且我认为值得付出努力。

只是为了表明我可以赞成打破常规;-)

@rgommers请再次阅读我写的内容:我不重复,不重复,建议NumPy应该采用LAPACK的步伐。

我明白那个。 我的答复中的两段没有直接联系,如果造成混淆,我们感到抱歉。

我建议,它向那些有这种期望的人(即我环境中80%的人)清楚地发出信号。

我就是这么说的,共识似乎是您的建议将被拒绝。 您将只需要将固定版本请求到该80%,然后解释为什么要这样做。

@khinsen好的,然后假装我的例子是索引的不兼容更改,如果可以的话,我们一定会做。 (花式索引有一些非常令人困惑的

@njsmith

旁注:我认为,花式索引是NumPy中最大的设计错误,因为它甚至没有(也从来没有)明确的规范。 对于整数参数,它执行np.take ;对于布尔参数,则执行np.repeat 。 由于布尔值是Python中整数的子类型,因此这为仅包含0和1的参数创建了歧义。

实际上与该线程的主题有关,因为这恰恰是开发进行得太快时发生的设计错误。

我在SciPy课程中专门讨论花式索引编制,以告诉人们不要使用它。 有np.takenp.repeat可以很好地工作并且不会造成麻烦。 而且,如果将它们用作函数而不是方法,则也没有OO问题。 对于那些不喜欢np.repeat因为该名称与布尔值结合使用时并没有暗示意图,只需引入一个别名: select = np.repeat 。 OO再次使不必要的困难变得困难。

还请注意,普通索引编制不会遇到任何此类问题。 它几乎在每个可能的情况下都可以做每个人都希望做的事情,因此可以用一种方法来实现。

我认为棘手的问题是算术。 您确实想写a+b来添加数组,而不是np.add(a, b) ,但是对于a+b应该做什么,尤其是在结果dtype方面,尚无普遍共识。 那是Numeric / numarray拆分的核心问题之一,这导致在NumPy中引入了新的标量类型,这也导致了它们所带来的令人不快的惊喜。 我相信这个问题可以解决,但不能在GitHub问题讨论的旁注中解决。

@rgommers如果“要求将固定版本的80%固定”是可能的,那么我早就已经做了。 “那80%”不是您可以与之交谈的有组织的社区。 拥有共同背景文化但彼此不互动的人很多。 您的建议有点像“要求Windows用户切换到Linux”(反之亦然)。

这就是我要坚持NumPy作为基础结构软件的观点。 对于许多人来说,构成软件安装的数百个乐高积木中只有一个。 他们并不特别在乎它,它只需要在这里工作即可。

我不想进一步破坏这一点,但我不知道您在使用np.repeat和bool数组指的是什么

@ eric-wieser重复0次,然后将其从数组中删除,保留1次。 我不同意使用这种方法而不是使用索引,但是无论如何(如今最糟糕的陌生感已经消失了,所以在大多数情况下,在numpy bool中并不是整数,我认为您现在还可以,因此甚至与列出您是否希望看到它,但是...)。

附带一点,因为无论如何这不再可行:)。 我实际上有点希望缓慢地修复numpy中的内容将使将来在某个时候更容易使numpy更具可替换性。

您的建议有点像“要求Windows用户切换到Linux”(反之亦然)。

嗯,让技术上熟练的人(我希望...)了解现实世界中的版本号是如何工作的,这实际上并不是Windows到Linux的切换。

这就是我要坚持NumPy作为基础结构软件的观点。

大概,如果我们要进行此切换,您将继续使用SciPy,因为它是基础架构的下一个组成部分? 什么时候停止成为基础设施? 为什么NumPy和其他基础设施希望拥有与Python本身以及整个科学Python生态系统的其余部分完全不同的版本控制方案?

“ 80%”不是您可以与之交谈的有组织的社区。

您使用的超级计算机的管理员真的应该互相交谈吗? 在那几个系统上,不可能有很多人到处运行所有更新软件,并且从不说话。 我并不是说您应该教育全世界80%的系统管理员,只是您需要的人。

@seberg声明列表和数组是不同的数据类型,它们仅将索引作为一个公共属性共享,这是采用的有效观点。 这也将使特定NumPy标量的存在更容易解释。 但是我还没有看到任何采用这种观点的NumPy演示。

@rgommers

您使用的超级计算机的管理员真的应该互相交谈吗?

不。他们甚至都不知道彼此的存在。 他们为不同地方的不同组织工作,它们的唯一共同点是拥有几个共同点。

我并不是说您应该教育全世界80%的系统管理员,只是您需要的人。

这不关我的事-我有一个对自己而言效果很好的解决方案:我总是在主目录中安装Python以及所有源代码库。

这是关于与我合作的人和向我寻求帮助的人(例如,因为他们过去参加了我的Python课程之一)。 他们没有技术能力来管理自己的Python安装并服从其他人(管理员或更有经验的同事)。

了解现实世界中的版本号如何工作

在我所考虑的人们共享的背景文化中,现实世界实际上就像语义版本控制或近似。

在我所考虑的人们共享的背景文化中,现实世界实际上就像语义版本控制或近似。

那是因为它们使用了数量有限的库,而大多数库都是缓慢运行的,例如LAPACK&co。 正如@njsmith指出的那样,大多数软件的版本号较低,因为它们不使用语义版本控制。

@rgommers他们确实使用了大多数缓慢移动的库,尽管我不会说“少数”。

正如@njsmith指出的那样,大多数软件的版本号较低,因为它们不使用语义版本控制。

根据我的经验。 但是,对于您我来说,“多数”可能意味着“我所知道的大多数”,并且在SciPy生态系统之外,您使用的软件包和我使用的软件包之间几乎没有重叠。

大概,如果我们要进行此切换,您将继续使用SciPy,因为它是基础架构的下一个组成部分? 什么时候停止成为基础设施?

我确实更希望SciPy和SciPy生态系统的所有其他基本原理都采用相同的原则,但是个人而言,我不会花任何精力在其他地方争辩,而不是NumPy,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。 还请注意,这些更改对系统管理员都没有任何意义,因此,即使他们长时间盯着这些说明(如果该值为2.0.0),他们也将无法决定升级是否可行或不。

还请注意,SciPy实际上使用语义版本控制,尽管可能不是故意的,因为它仅达到1.0。

SciPy使用与NumPy完全相同的版本控制方案和弃用/删除策略。 长时间处于0.x并不意味着semver。

正如我所见,它是科学计算中的主导者

SciPy生态系统的传统比较是使用Matlab和R之类的。找不到有关R的任何信息,但是它在3.x上并且已经发展了很多,因此可能不会简化。 Matlab:绝对不可以。

RE:花式索引。 实际上,这可以使用专用功能。 这是在TensorFlow中完成的操作,例如,使用tf.gathertf.gather_ndtf.scatter_ndtf.boolean_mask等等。结果比重载[] ,但肯定更加透明。

可以提供帮助的另一个功能是类型注释,该功能部分是由于Python 2到3过渡的难度所致。

我并不是说这很容易。 在我看来,社区带来的后果更大。 确实需要花很多精力才能实施,然后将其推向下游,例如SciPy。

@khinsen我整个星期都在关注讨论,我想我有一个实际的测试问题来测试您对此的看法。 这可能是一个很好的项目,以了解您的观点将如何处理此类冲突,而不是到目前为止的略微抽象的讨论。

当前,由于有了Apple Accelerate框架,最低要求的LAPACK版本是10年前的3.1.ish。 目前LAPACK为3.8.0。 同时,他们已经抛弃了许多例程(不建议使用和/或删除)并修复了许多错误,最重要的是,引入了新的例程来填补商业软件和Python科学软件之间的空白。 最终的结果归纳在这里。 在过去的6个月中,我一直在主要烦扰@rgommers和其他人,我可以向您保证,如果他们是那种人,您可能不情愿在这里刻画了这种情况,现在应该已经发生了,并破坏了许多人。 相反,他们一直在耐心地解释为什么放弃对Accelerate的支持并不是那么容易。

现在毫无疑问需要较新的版本。 那不是讨论,我们可以放心地跳过那部分。 NumPy和SciPy的很大一部分用户将从中受益。 但是我们不能仅仅因为您已经提出的论点而将其删除。 您将如何解决?

我并不是在用时髦的方式问这个问题,但是由于所有开发人员似乎都在想一想(而且我不得不说我同意他们的观点),也许您的外观可以给一个崭新的想法。 每当发生这种情况时,我们是否应该保持Accelerate并创建一个新的NumPy / SciPy软件包? 如果我们放弃支持以进行创新,那么您认为去这里的最佳方式是什么?

当前,由于有了Apple Accelerate框架,最低要求的LAPACK版本是3.1.ish

@mhvk ,这对于1,14中的#9976可能是个问题,我认为需要3.2.2(编辑:让我们开始讨论)

@xoviat :让我们就这个问题进行讨论

@ilayn感谢您将讨论

主要的共同点是:有不同的用户/社区有不同的需求。 一些人想要加速,另一些人想要新的LAPACK功能。 两者都有其特定优先事项的充分理由。 甚至有些人可能同时需要Accelerate新的LAPACK功能,尽管这对我来说还不清楚。

在Fortran / C世界中,没有这样的问题,因为软件堆栈较浅。 有Fortran,LAPACK和应用程序代码,没有其他中间体。 发生的情况是,每个应用程序代码都根据其优先级选择特定版本的LAPACK。 计算中心通常会并行保存几个LAPACK版本,每个版本都在自己的目录中,可以通过修改应用程序代码的Makefile来做出选择。

我们可以并且应该进入SciPy生态系统的教训是,选择软件版本不是软件开发人员的任务,而是组装特定于应用程序的软件捆绑包的人员的任务。 在我们的世界中,这是从事Anaconda,Debian和其他软件发行版工作的人员,还有各个级别的系统管理员和具有适当能力和动力的最终用户。

因此,我对SciPy / LAPACK困境的建议是保持Accelerate为今天的SciPy,但将其置于最小维护模式(可能由不同的人接管)。 想要加速的人可以选择“ SciPy 2017”并感到高兴。 他们不会获得新的LAPACK功能,但是大概大多数功能都可以。 开发将在新的命名空间( scipy2scipy2018或其他任何名称)中继续进行,该命名空间将切换到现代LAPACK。 如果在技术上可行,则允许并行安装这两个(以及将来的)变体(我认为SciPy应该可以)。 否则,需要两者同时使用的人将不得不使用多个环境(通过Nix或Guix的conda,venv或系统范围的环境)。 请注意,即使在第二种情况下,我也强烈建议您通过每次不兼容的更改来更改名称空间,以确保任何级别的Python代码读者都可以理解该代码是为哪个SciPy版本编写的。

总体思路是,开发人员会提出新的建议(并专注于其开发),但不要在一般意义上将其宣传为“更好”,也不作为通用替代品来宣传。 为特定任务选择正确的软件版本组合不是他们的工作,而是其他人的工作。

一般的想法是,开发和组装是由不同的人独立完成的,这也表明,当今的大型包装应分解成较小的单元,以不同的速度发展。 今天没有理由让NumPy包含一个小的LAPACK界面和f2py 。 对于SciPy来说,拥有一个指示一致性的通用名称空间和一个通用的开发策略可能是有意义的,但是子包可以独立地分布。 大型封装方法可以追溯到20年前Python的座右铭。 当今的用户基础太多样化了,软件打包通常被认为是一项独特的活动。 现在,包括电池应该是Anaconda的工作。

采用这种方法的主要障碍是传统的Linux发行版,例如Debian或Fedora,其“每台机器一个Python安装”方法。 我认为他们可以通过合理的努力切换到多个系统范围的虚拟环境,但是对此我并没有考虑太多。 对我而言,软件打包的未来是基于环境的系统,例如conda或Guix。

我看不到您到目前为止提出的所有介词与这些步骤中的任何一个兼容

  • 您刚刚重现了以下图片的疯狂之处
    image
    只是算了一下,我的Windows机器上现在有27份了。 现在将其乘以10(因为此处的发布频率更高)和2(因为NumPy和SciPy的发布周期是独立的)。 在2025年,我很容易获得每个库的15个副本以及10个LAPACK和5个f2pys的依赖关系。 更不用说两个软件包中只有十几个人的维护负担了,这根本行不通。 (C ++不相关,请插入任何标准库)。 向任何商业代码开发人员咨询Win,并告诉他们这是一个好主意。 对于这次交流的后续活动,我不承担任何责任。
  • 然后,您增加了软件包的粒度,现在可以使用不同的软件包版本自行处理。 f2py在一个版本中破坏了某些内容,因此SciPy在下一个版本中停止构建,但仍依赖于NumPy的早期版本。 因此,某些整体实体应将它们免费组合在一起。
  • 然后,就像Accelerate一样,您也使Anaconda(或其他实体)成为一家主要依赖的公司。 或只是会有大量的“其他人”。
  • 然后,您将大多数用户群调动到他们真正不希望(包括我自己)涉及虚拟环境的工作流程中。
  • 然后,您甚至顺带修改了Linux操作系统(这是...我的意思是只阅读了它们的一些邮件列表,这很有趣)。

也许你离题了一点。

(这已成为免费讨论,因此我将继续讨论)。

保持对加速的支持的问题并不在于它缺少更新的LAPACK API。 如果这是问题所在,我们可以交付较新的LAPACK垫片并完成。 问题是在某些情况下,有些基本函数会返回不正确的结果。 除了编写我们自己的BLAS函数之外,没有其他方法可以解决此问题。 如果这样做的话,我们可能还需要OpenBLAS或MKL。

@xoviat这些已在https://github.com/scipy/scipy/pull/6051中进行了讨论

@ilayn是的,我确定已经知道我要提出的观点。 但是评论是针对@khinsen的; 我认为他的印象是我们实际上可以保持Accelerate支持。

有人可能会说,Python生态系统的一项功能(或局限性)是,您可以获得一个版本的库,而没有令人讨厌的名称修改技巧。 这发生在核心Python中。 这就是为什么有一个名为_lib_ _lib_ 2,有异曲同工之妙,但API的差别库和。 甚至矿石Python都以这种方式工作。 即使在技术上都可以在现代Python上使用标准库,而无需有人翻录并将其放在PyPi上,也不可能在各个版本中混合使用标准库。 关于此问题有很多问题都具有相同的结论。

@ilayn如果出于某种原因,您希望在计算机上拥有所有版本的所有可能的组合,是的,那是一团糟。 但是,为什么要这样呢? 如果您将自己限制为实际需要的应用程序组合,我敢打赌,它将减少。 举例来说,我在机器上只保留了两个Python环境:一个运行Python 2 + NumPy 1.8.2,用于运行已有20年历史的代码,另一个代表大约两年前的最新状态(两年前,因为我是两年前设置的,之后再也没有看到升级的理由了。

关于粒度,我的主张可能不太清楚。 我主张的是包装的粒度,而不是开发的粒度。 我希望f2py和SciPy的开发能够继续保持密切协调。 f2py-2018和SciPy-2018应该一起工作。 这并不意味着它们必须打包为单个实体。 目的是为软件发行经理提供更大的自由来进行工作。

我绝对不想让Anaconda或任何其他发行版成为依赖性。 尽管我不认为发行版的数量会增加到“大量”,但考虑到组装它们的工作量很大,尽管这并不像“别人丰富”。

我不知道“用户群”想要什么工作流。 我看到许多具有不同要求的不同用户群。 就个人而言,我会选择多个环境,但是如果有大量的用户群希望每台计算机使用一个环境,则可以通过一些分发来解决。 但是虚拟环境的发明是有原因的,它们解决了一个实际的问题。 Nix或Guix之类的系统级发行版将它们带入了另一个层次。 我不希望他们消失。

顺便说一句,我实际上是遵循一种Linux发行版(Guix)的邮件列表。 娱乐性不高,但是扎扎实实的工作很多。 我很高兴有人这样做。

@xoviat我不建议“保持加速支持”。 我只是建议保留一个SciPy变体(目前的版本差不多),而不是作为博物馆的过时版本,而是作为特定用户群感兴趣的变体:对于那些使用Accelerate的人来说,解决问题比解决问题更重要加速为他人创造。 “加速第一”的人民将不得不承受自己选择的后果。 有些问题永远不会为他们解决。 对他们来说可能很好(“已知错误要比未知错误更好”),那么为什么要迫使它们变成不同的东西呢?

实际上,所有这些都与标签和沟通有关。 我想摆脱线性发展过程中理想化的软件形象,更新的版本“更好”,如“更高”的版本号所示。 我想用我认为更现实的图像替换该图像:软件版本之间没有明显的顺序关系。 由长期存在的,一致的开发人员社区生产的产品具有时间顺序,但这并不意味着有关任何给定应用程序的质量或适用性。

如果理想化的映像是正确的,那么我们将不会看到分叉,也不会拥有虚拟环境。 也没有像VersionClimber这样的项目。

我建议的是,软件开发人员应该接受这个现实,而不是否认它。 他们应该为多样化的世界开发(最重要的是包装和贴标签)他们的产品。

@khinsen如果您对线性代数函数的不正确结果感到满意,那么我们可以继续提供加速支持(请注意其他人:我知道该怎么做)。 但是,主要问题是您可能是唯一想要此功能的人。 即使您不是,当路上有人将SciPy的加速问题归咎于SciPy时

@xoviat不,我不满意线性代数函数的错误结果。 但是我敢肯定,有很多SciPy用户根本不需要受影响的功能。 在您提到的线程中,有人建议在检测到Accelerate时删除/停用受影响的功能,我认为这是一个很好的解决方案(请注意:我无法判断实现此功能所需的工作量)。

从某种意义上讲,这是大包装问题的一部分。 使用更细粒度的分发,可以更轻松地选择在开发和分发组装级别都起作用的东西。 甚至可以想象一个分布组装程序,它构成了特定于域和平台的SciPy分布,其中不同的子包使用不同的LAPACK版本,例如,在HPC上下文中使用。

但是我敢肯定,有很多SciPy用户根本不需要受影响的功能。

这种说法的证据极少,我实际上会反其道而行之。 这些功能已被广泛使用,但仅在某些情况下会失败。 换句话说,您的结果可能正确,但可能不正确。 是的,如果使用OSX,这可能适用于您当前安装的SciPy。 是的,这个问题需要解决。

至于维护一个单独的分支,我认为没有人会反对给您维护对特定分支的写权限。 但这是开源软件,人们可以根据自己的意愿进行工作。 我怀疑很多人会对维持该分支机构感兴趣。

实际上,我认为anaconda SciPy是使用MKL编译的,因此在这种情况下您不会受到影响。 但是,为什么您要关心加速支持?

@xoviat这里似乎有很大的误会。 在这个特定的问题上,我一点也不关心。 我没有使用SciPy的任何线性代数例程。

您指出了一个有关SciPy问题的话题,并询问我将如何处理这种情况。 该线程清楚地表明不愿简单地放弃Accelerate支持,据此我推断有一个很大的用户组会受到此类更改的影响。 如果该用户组不存在,那么问题出在哪里? 为什么SciPy尚未放弃Accelerate支持?

@xoviat维护任何人的分支都很容易。 无需将其托管在相同的GitHub存储库中。 换句话说,分支不是问题。 问题是命名空间,以使单独的SciPy版本的并行存在对用户(和分发组装者)透明。

今天,当您看到说“ import scipy”的代码时,您不知道应该在哪个SciPy版本范围内工作(即已经过某种程度的测试)。 在最佳情况下,有一个自述文件,内容为“ SciPy> = 0.8”或类似的内容。 这个习惯是基于这样的假设,即“较高”版本始终是“较好”版本,并且从不降级(破坏,减速等)。 这个假设完全是错误的。

另一方面,如果代码说“将scipy2017导入为scipy”,则每个读者都清楚地知道,将其与较早或更高版本一起使用可能会引起很多意外。 而且,如果旧的SciPy版本消失了(实际上是由于缺乏维护),那么这样的代码将失败并显示错误消息,而不是继续不可靠地工作。

这是我试图在此主题中提出的观点。 不同版本的共存是现实。 越高越好的想法是一个梦想。 让我们变得现实并为现实世界组织自己,方法是承认一个多版本的宇宙,并调整每个人的沟通方式以防​​止误解。

好吧,dunno…在我看来,关于警告,特定版本的导入不是警告,它禁止使用其他版本,因为遇到您所描述的问题的用户将不敢更改您的代码。 如果您在安装/运行时打印警告,则除特定的numpy版本外,所有其他版本都未经测试,这将是一个警告?

我想可以创建这种类型的额外程序包。 我也希望它会创建另一种类型的地狱。 许多可能仍然存在,但是例如,当您将两个版本混合使用时,类型检查将不会也不会,因此基本上您将不知道它是否可以工作,直到您尝试为止(而且没人会对此进行测试!)。
除非您建议允许混合使用两个版本,否则我认为您的scipy2017解决方案只会使情况变得更糟。 似乎我们需要选择动态/运行时虚拟环境(例如在Python级别上进行任何导入之前的pin_import_version("1.6<numpy<1.10", level="raise") )。

如果您有重大的禁止性更改(例如py2 / py3),则特定的导入是有意义的,并且我们已经看到,对于“主要”行似乎在什么时间尺度上或在什么时间尺度上存在不同的看法。

向后兼容NEP#11596已提交,我们可以解决这个问题吗?

向后兼容NEP#11596已提交,我们可以解决这个问题吗?

是的,我们可以关闭它。 独立于该NEP(明确将semver视为被拒绝的替代方案),此处核心开发人员的共识是我们不想更改为semver。 因此关闭作为wontfix。

感谢大家的讨论。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

keithbriggs picture keithbriggs  ·  3评论

toddrjen picture toddrjen  ·  4评论

inducer picture inducer  ·  3评论

manuels picture manuels  ·  3评论

Foadsf picture Foadsf  ·  3评论