Numpy: 기능 요청 : 시맨틱 버전 관리 사용

numpy는 의미 론적 버전 관리를 사용하는 것으로 간주 될 수 있지만 선행 1 ?

거의 모든 핵심 과학 Python 프로젝트가 NumPy가하는 일을한다는 점에 유의하십시오. 매우 지장을주지 않는 한 몇 번의 릴리스 후에 사용되지 않는 코드를 제거하고 주요 사항에 대한 주요 버전 번호 만 올립니다.

지원 중단 정책에 대한 변경을 제안하는지 또는 지금 1.14.09 버전이 아닌 14.0.0 버전이어야한다고 생각하는지 확실하지 않습니다.

후자 : NumPy는 현재 대략 버전 14에있을 것입니다. 그러나 나는 향후 릴리스에만이 규칙을 채택 할 것을 제안합니다.

BTW : NumPy의 전임자 인 Numeric은 시맨틱 버전 관리를 사용했고 대략 10 년에 걸쳐 버전 24에 도달했습니다. NumPy 로의 전환에서 이것이 왜 변경되었는지 모르겠습니다.

내 인상은 대부분의 Python 프로젝트가 의미 론적 버전 관리를 사용하지 않는다는 것입니다. 예를 들어, Python 자체는 시맨틱 버전 관리를 사용하지 않습니다. (저는 또한 semver를 사용하는 주류 운영 체제 나 컴파일러에 대해 알지 못합니다. 염두에두고있는 것이 있습니까?) 저는 semver 지지자들이 마케팅을 훌륭하게 수행하여 많은 개발자들이 그것이 좋다고 생각하게 만들었다는 데 동의합니다. 하지만 AFAICT는 왼쪽 패드보다 큰 프로젝트의 경우 실제 세계에서 본질적으로 작동하지 않습니다. 저는 semver 사람들이 이제 전통적인 MAJOR.MINOR.MICRO 형식을 "소유"하고 다른 모든 사람들이 무언가로 전환해야한다는 생각에 강력하게 이의를 제기합니다. 그밖에.

"의미 적 버전 관리로 착각 할 수없는 릴리스 레이블 지정 체계"가 의미하는 바의 예를 들어 줄 수 있습니까? 숫자 대신 이름을 사용하십니까? 날짜 기반 버전 관리를 인용했지만 내가 본 가장 일반적인 체계는 현재 각각 17.9.0 및 17.5.0 인 Twisted 및 PyOpenSSL에서 사용하는 체계입니다. 저에게는 완전히 그럴듯한 semver 버전처럼 보입니다 ...

그리고 이것이 사용자에게 어떤 혜택을 줄 수 있는지 자세히 설명해 주시겠습니까? 이 가상의 미래에서 모든 릴리스에는 지금과 같이 대부분의 사용자와 무관 한 몇 가지 주요 변경 사항이 있습니다. 몇 달에 한 번씩 주요 번호를 올림으로써 어떤 유용한 정보를 전달할 수 있을까요? "아마 누군가를 망가 뜨리지 만 아마 당신을 망가 뜨리지는 않을 것입니다."? 우리는 또한 버그 수정 릴리스에서 주요 버전을 범프해야 하는가? 실제로 혼란 스러웠던 "소프트웨어 개발자, 소프트웨어 사용자 및 소프트웨어 배포 관리자"의 예를들 수 있습니까?

메일 링리스트는이 토론에 더 적합한 장소이며 실제로 변경하기 전에 토론을해야 할 수도 있지만 여기에있는 의견은 원하는 문제의 종류를 파악하는 데 유용해야합니다. 그 토론에서 다룰 수 있습니다.

@njsmith 우리가 동의하지 않는 유일한 사실은 시맨틱 버전 관리가 오늘날 기본 가정인지 여부입니다. 이를 위해서는 기본값 인 (또는 그렇지 않은) 커뮤니티에 대한보다 명확한 정의가 필요합니다. 내가 신경 쓰는 소프트웨어 관리 수준은 배포 관리 및 시스템 관리로, 사람들이 자신의 상황에 가장 적합한 버전을 결정하는 곳입니다.

의미 론적 버전 관리가 기본값이라는 결론을 내린 비공식적 인 질문은 과학 컴퓨팅 설치 관리자와 대화하는 것으로 구성되었습니다. 나는 또한 상상했다
좀 더 경험적인 접근 방식 (최근 데비안 설치에 패키지를 나열하고 버전 관리 방식을 조사하기 위해 무작위로 몇 개를 선택 함)이 매우 어려웠습니다. 시맨틱 버전 관리를 사용하는지 여부를 명확하게 설명하는 프로젝트가 거의 없기 때문입니다.

한 시스템 관리자의 의견은 특히 관련성이 있다고 생각했습니다. 그는 설치할 버전을 결정하기 위해 의미 론적 버전 관리 이외의 어떤 규칙도 쓸모가 없다고 말했습니다. 시스템 관리자는 각 패키지를 자세히 살펴 보거나 (시간과 역량이 부족함) 모든 사용자 (너무 많은 경우)와상의 할 수 없습니다. 그들은 통일 된 정책을 채택해야하며 이것은 의미 론적 버전 화의 가정에 기반하는 경향이 있습니다. 예를 들어, 컴퓨팅 클러스터의 관리자는 메이저 버전 번호가 변경된 업데이트를 적용하기 전에 개인적으로 알고있는 몇 명의 "고급 사용자"를 확인한다고 말했습니다.

실제로 과학적 Python 사용자와 관련하여 실제로 혼란스러워하는 사람들의 예로는 직장 동료, 컨퍼런스에서 만나는 사람들, 이메일로 조언을 요청하는 사람들, 수업에 참여하는 학생들 등 많은 사람들이 있습니다. 이것은 일반적으로 "나는 당신이 Python 전문가라는 것을 알고 있습니다. 문제를 해결해 줄 수 있습니까?"로 시작합니다. 이 문제는 한 컴퓨터에서는 작동하지만 다른 컴퓨터에서는 작동하지 않는 스크립트로 밝혀졌습니다. 이들 중 대부분은 종속성 문제를 전혀 고려하지 않지만, 일부는 실제로 두 설치의 버전 번호를 비교하여 "작은 차이"만 발견했습니다.

@ eric-wieser와 @rgommers가 언급했듯이 내 요청은 초기 "1"을 요청하는 것과 거의 동일합니다. NumPy 버전에서 삭제됩니다. 즉, NumPy는 사실상 정책 결정의 결과가 아니므로 엄격하게 수행되지 않았더라도 이미 시맨틱 버전 관리를 사용합니다. 그러나 NumPy가 현재 개발 워크 플로를 거의 변경하지 않고 의미 론적 버전 관리를 채택 할 수 있음을 시사합니다.

한 시스템 관리자의 의견은 특히 관련성이 있다고 생각했습니다. 그는 설치할 버전을 결정하기 위해 의미 론적 버전 관리 이외의 어떤 규칙도 쓸모가 없다고 말했습니다.

불행히도 의미 론적 버전 관리도 쓸모가 없습니다. :-(. 나는 머리카락을 쪼개거나 과장하려는 것이 아닙니다. 나는 그것이 진짜 문제라는 것을 완전히 이해합니다. 그러나 문제가 진짜라고해서 해결책이 있다는 것을 의미하지는 않습니다. 근본적으로 "이 소프트웨어를 업그레이드해야합니까?"라는 질문을 단순한 기계 검사로 요약 할 수 없습니다. 환상입니다. semver를 사용하는 프로젝트는 모든 사용자가 즉시 업그레이드해야하는 주요 릴리스를 정기적으로 만들고 사소한 변경을 정기적으로 수행합니다. 릴리스.

시스템 관리자는 각 패키지를 자세히 살펴 보거나 (시간과 역량이 부족함) 모든 사용자 (너무 많은 경우)와상의 할 수 없습니다. 그들은 통일 된 정책을 채택해야하며 이것은 의미 론적 버전 화의 가정에 기반하는 경향이 있습니다. 예를 들어, 컴퓨팅 클러스터의 관리자는 메이저 버전 번호가 변경된 업데이트를 적용하기 전에 개인적으로 알고있는 몇 명의 "고급 사용자"를 확인한다고 말했습니다.

나는이 부분을 좋아한다 :-). 나는 우리가 semver의 철학에 대해 동의 할 것 같지는 않지만, 다른 버전 관리 체계의 구체적인 효과와 우리가 가장 바람직한 결과에 대해 토론하는 것이 훨씬 쉽습니다.

semver의 개념이이 정책과 많은 관련이 있다고 생각하지 않습니다. 시스템 관리자가 실제로 모든 프로젝트를 확인하여 semver를 사용하고 있는지 확인합니까? 대부분의 프로젝트는 당신이 말했듯이 어떤 프로젝트가 수행하는지조차 말하기 어렵습니다. 그리고 정책은 semver가 존재하기 오래 전부터 시스템 관리자가 사용해온 것과 동일합니다. 이 정책의 더 나은 특성은 "업그레이드에 얼마나주의해야하는지에 대한 프로젝트의 권장 사항을 따르십시오"와 함께 주요 릴리스는 "크고"마이너 릴리스는 "작게"라는 고대 전통을 따르는 것입니다.

NumPy 프로젝트의 권장 사항은 시스템 관리자가 새로운 기능 릴리스로 업그레이드해야한다는 것입니다. 그래서이 일화에서 제가 취한 것은 현재 번호 지정 체계가 우리가 원하는 것을 정확하게 전달하고 있고 semver로 전환하면 그렇지 않다는 것입니다.

@njsmith 좋아요, 철학과 실용성에서 벗어나 소프트웨어 개발자, 시스템 관리자, 소프트웨어 사용자 간의 커뮤니케이션에서 소프트웨어 버전 번호의 역할은 무엇입니까?

다시 한 번 우리는 여기에 큰 의견 차이가있는 것 같습니다. 당신을 위해 시스템 관리자와 사용자에게 지침을 제공하고 버전 번호를 사용하여 지침을 전달하는 것은 개발자입니다. 저에게는 모든 플레이어가 자신의 기준에 따라 결정해야하며 버전 번호는 가장 거친 수준에서 사실에 입각 한 커뮤니케이션 수단으로 작용해야합니다.

NumPy가 보안에 영향을주지 않는다는 점을 감안할 때 NumPy 프로젝트가 보편적 인 권장 사항을 제공해야하는 방법과 이유를 알 수 없습니다. 사람과 기관은 서로 다른 요구를 가지고 있습니다. 이것이 우리가 매우 다른 업데이트 정책을 가진 ArchLinux와 CentOS를 모두 가지고있는 이유입니다.

@khinsen oldnumeric 패키지는 여전히 완벽하게 작동하며 다음과 같이 설치할 수 있습니다.

pip install oldnumeric

아마도 이것은 numpy에 대한 인터페이스가 Python / Cython으로 제한되고 아무것도 변경되지 않는 제안 된 "안정적인 numpy"일 수 있습니다. 물론 oldnumeric으로 코드를 작성하는 것은 매우 난해하지만 두 가지 방법을 모두 가질 수는 없습니다.

@xoviat 사실이지만 그것은 다른 문제입니다. 여기서 내 요점은 소프트웨어 보존이 아니라 소프트웨어 관리 분야에서 서로 다른 플레이어 간의 커뮤니케이션입니다.

질문 : 시스템 관리자로서 (개인용 컴퓨터에서도) 패키지가 버전 1.8에서 버전 1.9로 완전한 API 계층을 삭제할 것으로 예상합니까?

"예"라고 답한 사람들에게 두 번째 질문입니다. 이렇게 한 적이있는 numpy 이외의 소프트웨어 이름을 지정할 수 있습니까?

BTW, 나는 많은 사람들이 이것에 물렸다는 것을 확신 할 수 있습니다. 왜 MMTK가 하루에서 다음 날로 작동을 중단했는지 묻는 많은 메일을 받았기 때문입니다. 이 모든 사람들은 심각한 결과를 기대하지 않고 소프트웨어 설치를 정기적으로 업데이트했습니다.

그러나 oldnumeric 떨어 뜨리는 것은 최근 NumPy 역사상 최악의 사건은 아니 었습니다. 그 영광은 diagonal 와 같은 일부 작업의 복사 /보기 의미를 변경하는 것입니다. NumPy 버전 (부 버전 번호 변경!)에 따라 다른 결과를 반환하는 코드는 정말 악몽입니다.

: BTW, 이후 거의 사람이 이야기를 알고 pip install oldnumeric @xoviat이 추가 패키지를 준비하고 PyPI에 넣어 때문에 이틀 전부터 작품. 감사합니다!

패키지가 버전 1.8에서 버전 1.9로 완전한 API 계층을 삭제할 것으로 예상합니까?

어떤 레이어를 참조하고 있습니까?

이 작업을 수행 한 numpy 이외의 소프트웨어 이름을 지정할 수 있습니까?

SciPy는 weave 및 maxentropy 패키지를 삭제했으며 pandas 는 주요 기능을 정기적으로 중단합니다. 더 많은 저명한 예가 있다고 확신합니다. 편집 : 예를 들어 Python 자체, https://docs.python.org/3/whatsnew/3.6.html#removed 참조

BTW, 나는 많은 사람들이 이것에 물렸다는 것을 확신 할 수 있습니다. 왜 MMTK가 하루에서 다음 날로 작동을 중단했는지 묻는 많은 메일을 받았기 때문입니다. 이 모든 사람들은 심각한 결과를 기대하지 않고 소프트웨어 설치를 정기적으로 업데이트했습니다.

그 변화는 약 10 년 동안 이루어졌고, 다른 버전 관리 체계가 여기에서 차이를 만들 수있는 방법은 없습니다.

더 이상 사용되지 않는 기능을 삭제하는 것은 (오래된) 코드의 일부를 분리하는 것과 코드베이스를 쉽게 유지 관리하는 것 사이의 균형입니다. 전반적으로 우리가 잘못했다면 보수적 인 측면에서 그렇게 할 가능성이 높습니다. numpy를 사용하는 수년 전의 대기업 코드베이스를 다뤄야했던 사람으로서 저는 고통을 느끼지만 절대 해결책이 아닌 것을 주장하고 있습니다 (일반적으로 완전한 해결책은 없습니다. 버전 고정 및 지원 중단 경고 확인과 같은 작업이 최선의 방법입니다.

어떤 레이어를 참조하고 있습니까?

내가 가정하는 숫자 / numarray 지원

@rgommers 죄송합니다. "SciPy 생태계 외부 의 또 다른 예"라고 말 했어야했습니다.

또한 oldnumeric 대한 지원 중단에 대해 불평하지 않습니다. 주 버전 번호를 변경하지 않고 이렇게하는 것에 대해 불평하고 있습니다.

그게 어떤 차이를 만들었 을까요? 사람들이 릴리스 노트를 읽지 않고 업데이트하는 것을 주저하게 만들었을 것입니다. 파이썬 코드를 사용하는 (개발하지 않는) 모든 사람들은 이것을 조심해야 할 신호로 받아 들였을 것입니다.

SciPy 생태계에는 개발을 적극적으로 따르지 않는 수많은 로우 프로필 사용자가 있다는 것을 잊지 마십시오. Python 및 NumPy는 ls 및 gcc 와 동일한 특성의 인프라 항목입니다. 그리고 종종 그보다 적습니다. 그들은 Python으로 작성되고 NumPy에 의존하는 일부 소프트웨어를 사용하며 중단되면 완전히 손실됩니다.

@rgommers 죄송합니다. "SciPy 생태계 외부의 또 다른 예"라고 말 했어야했습니다.

방금 SciPy 생태계 외부에있는 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 개의 패키지가 설치된 데비안 9 시스템을 빠르게 확인했습니다. 그들 중 85 %는 정수로 시작하여 점이 오는 버전 번호를 가지고 있습니다. 가장 일반적인 정수 접두사는 1 (30 %), 2 (26 %), 0 (14 %) 및 3 (13 %)입니다. NumPy가 일반적인 기대에 부합하는 버전 번호 지정 체계 (즉, 의미 적 버전 지정 또는 근사치)를 채택하면 확실히 눈에 띄고주의해서 취급됩니다.

데비안이 설치 한 소프트웨어의 유일한 업데이트는 집에서 만든 조직 모드 확장을 깨뜨린 조직 모드를 변경 한 Emacs 업데이트를 제외하고는 SciPy 생태계에있었습니다. 따라서 전체적으로 낮은 버전 번호 접두사는 가장 널리 사용되는 소프트웨어가 NumPy 및 친구들보다 훨씬 더 안정적이라는 것을 나타냅니다.

SciPy 생태계 전반에 걸친 통일성은 실제로 중요하지만 전체 생태계가 외부 세계의 기대에 부합하는 버전 관리 체계를 채택하는 것을 선호합니다. 나는 NumPy를 가장 기본적인 부분으로보기 때문에 단지 NumPy로 시작하는 것입니다. 다른 무엇보다 더 많은 인프라입니다.

마지막으로 함수 의미의 변경은 ABI의 변경보다 훨씬 더 중요한 변경이라고 생각합니다. 전자는 수백 명의 사용자에게 디버깅 악몽을 일으킬 수 있으며 프로그램이 수년 동안 감지되지 않은 잘못된 결과를 생성하도록 만들 수 있습니다. 후자는 무언가를 수정해야 함을 명확하게 나타내는 오류 메시지로 이어집니다.

이러한 표준에 따르면 NumPy는 Python의 선두를 따르지 않습니다. 왜냐하면 Python 언어에서 내가 알고있는 의미 체계의 유일한 변경은 2에서 3으로 발생했기 때문입니다.

마지막으로 함수 의미의 변경은 ABI의 변경보다 훨씬 더 중요한 변경이라고 생각합니다. 전자는 수백 명의 사용자에게 디버깅 악몽을 일으킬 수 있으며 프로그램이 수년 동안 감지되지 않은 잘못된 결과를 생성하도록 만들 수 있습니다. 후자는 무언가를 수정해야 함을 명확하게 나타내는 오류 메시지로 이어집니다.

이것은 우리가하지 않기 위해 정말 열심히 노력합니다. 일부 기능이 제거 될 때 명확한 파손이 발생할 수 있으며, 수치 결과를 조용히 변경해서는 안됩니다. 그것은 우리가 대각선 뷰 변경에서 배운 것 중 하나입니다.

확실히 눈에 띄고 조심스럽게 다루어 질 것입니다.

나는 여전히 동의하지 않는다. 데비안에서도 사용자 기반의 "일반적인 소프트웨어 설치"는 아닙니다 (Windows의 Anaconda와 비슷합니다). 또한 사용자가 정상적으로 버전 번호를 볼 수 없다는 위의 주장을 무시하는 것 같습니다 ( pip install --upgrade 또는 패키지 관리자를 사용하지 않음).

또한 다른 큰 종속성 체인이 아닌 OS 유틸리티 및 GUI 프로그램과 같은 것을 사용하고 있기 때문에 다른 모든 것이 결코 깨지지 않는다는 경험이 있습니다. 예를 들어 전체 JavaScript / NodeJS 생태계는 아마도 Python보다 더 취약 할 것입니다.

BTW, 나는 많은 사람들이 이것에 물렸다는 것을 확신 할 수 있습니다. 왜 MMTK가 하루에서 다음으로 작동을 멈췄는지 묻는 많은 메일을 받았기 때문에

이것은 여기에서 미묘함의 좋은 예입니다. 내가 아는 한, MMTK와 다른 프로젝트는 숫자 / numarray 호환성 코드 제거로 인해 영향을받은 유일한 프로젝트입니다. 얼마나 많은 사용자가있을 것으로 예상하십니까? 100? 1000? NumPy는 수백만 개를 보유하고 있는데 사용자의 0.1 %가 이번 제거로 인해 영향을 받았을까요? 이것은 확실히 0이 아니며, 그것이 작다는 사실이 중요하지 않다는 것을 의미하지는 않습니다. 모든 방법으로 100 % 사용자를 영원히 지원할 수 있기를 바랍니다. 그리고 사용자로부터 100 % 불만을받는 것이 특히 고통 스럽다는 것을 이해합니다.

하지만이를 위해 주 버전 번호를 올리면 사용자의 99.9 %가 울프를 울렸다는 뜻입니다. 오탐입니다. 0.1 %의 사용자에게는 OTOH가 정말 중요했습니다. 그러나 최선의 노력에도 불구하고 마이크로 릴리스에서 사용자의 0.1 % 이상을 깨뜨리는 것은 드문 일이 아닙니다. 그래서 우리는 무엇을합니까?

버전 번호의 무딘 도구를 통해 이러한 뉘앙스를 전달할 수는 없습니다. 누구나 업그레이드로 인해 코드가 손상되는지 여부를 신속하게 알 수있는 방법을 원합니다 . Semver는 그렇게 할 것을 약속하기 때문에 인기가 있습니다. 유행하는 다이어트가 암을 치료할 수 있다고 생각하는 것과 같은 이유로 인기가 있습니다. 나는 semver도 약속대로 살기를 바랍니다. 하지만 그렇지 않습니다. 우리가 좋은 엔지니어가되고 싶다면 그 현실의 복잡성을 다뤄야합니다.

NumPy 프로젝트가 보편적 인 권장 사항을 제공해야하는 방법과 이유를 알 수 없습니다. 사람과 기관은 서로 다른 요구를 가지고 있습니다.

버전 번호가 하나뿐이므로 보편적 인 권장 사항을 제공하므로 정의에 따라 우리가 수행하는 모든 작업은 보편적 인 권장 사항입니다. 그것은 우리가 통제 할 수있는 것이 아닙니다.

그 영광은 diagonal 와 같은 일부 작업의 복사 /보기 의미를 변경하는 것입니다.

IIRC 우리는 누군가의 코드를 위반했다고 말하는 누군가로부터 이것에 대해 말 그대로 단일 불만을받지 못했습니다. (어쩌면 한 사람일까요?) 아무도 영향을받지 않았다는 뜻이 아닙니다. 분명히 변화에 대해 불평하는 사람들은 일반적으로 영향을받는 사람들의 극히 일부에 불과하지만 불만을 실제 대리로 사용한다면 세계에 미치는 영향은 이것이 상위 50 위를 차지하지 않는다고 생각합니다.

그리고 BTW 나는 당신이 깊은 역사를 살펴보면 그보다 훨씬 더 심각한 변화를 찾을 수 있다고 확신합니다 :-).

데비안이 설치 한 소프트웨어의 유일한 업데이트는 집에서 만든 조직 모드 확장을 깨뜨린 조직 모드를 변경 한 Emacs 업데이트를 제외하고는 SciPy 생태계에있었습니다.

정중하게도 이것은 NumPy 대 Debian보다 NumPy 대 Debian을 사용하는 방법에 대해 더 많이 말합니다. 나는 데비안을 사랑하고, 거의 20 년 동안 그것을 사용해 왔고, 그것이 몇 번이나 고장 났는지 셀 수 없습니다. 지난주에 새로운 그놈의 기괴한 문제로 인해 로그인 스크립트 가 깨졌고 다른 업그레이드로 인해 -Werror 사용하는 것과 같은 일을하고 경고 동작을 약간 변경하기 때문에 (미묘하게 의존 할 수있는) gcc 릴리스와 같은 것이 있다고 생각하지 않습니다. 최적화 과정 간의 상호 작용 등)은 주요 변경 사항이됩니다.

따라서 전체적으로 낮은 버전 번호 접두사는 가장 널리 사용되는 소프트웨어가 NumPy 및 친구들보다 훨씬 더 안정적이라는 것을 나타냅니다.

전체적으로 낮은 버전 번호 접두사는 가장 널리 사용되는 소프트웨어가 semver를 사용하지 않기 때문입니다.

마지막으로 함수 의미의 변경은 ABI의 변경보다 훨씬 더 중요한 변경이라고 생각합니다. 전자는 수백 명의 사용자에게 디버깅 악몽을 일으킬 수 있으며 프로그램이 수년 동안 감지되지 않은 잘못된 결과를 생성하도록 만들 수 있습니다. 후자는 무언가를 수정해야 함을 명확하게 나타내는 오류 메시지로 이어집니다.

그렇기 때문에 우리는 그러한 변화를 극도로 경계합니다.

여기에는 관점에서 약간의 단절이 있습니다. 당신은 우리가 항상 일을 아무렇게나 바꾼다고 생각하는 것 같고, 이전 버전과의 호환성은 신경 쓰지 않습니다. 저는 그것을 존중할 수 있습니다. 나는 그것이 당신의 경험을 반영한다는 것을 이해합니다. 하지만 우리의 경험은 우리가 그러한 변화에 극도의주의를 기울 였다는 것입니다. 그리고 제가 사용자들과 이야기 할 때, 당신의 관점을 가진 사람은 ~ 5 %이고, numpy가 안정성에서 좋은 일을하고 있다고 느끼는 사람은 ~ 95 %입니다. 또는 너무 좋은 일을하고 있고 더 기꺼이 일을 깰 수 있어야합니다. 아마도 우리가 당신을 실망시킨다해도 우리는 마지막 그룹을 실망 시킨다는 사실을 알고 위로를받을 수있을 것입니다 :-).

Emacs 업데이트를 제외하고는

글쎄, 주제를 벗어난 것은 안정성의 다른 측면의 예입니다. Emacs는 Stallman의 변화에 ​​대한 저항으로 인해 수년간 정적이었으며, 그 결과 xEmacs 포크가 발생했습니다. 내 자신의 길은 Emacs-> xEmacs로 갔다.-> Vim;) 조기 화석화는 내가 예전에 데비안 사용을 중단 한 이유이기도하다. 어떤 경우에는 단순히 변경이 필요하지 않거나 원하지 않으며, 옷장에 숨겨져있는 오래된 하드웨어에서 고대 버전의 BSD를 실행하는 사람들이있을 것으로 예상합니다. 하지만 그런 곳이 많을 거라고는 생각하지 않습니다.

현재 문제에 대해서는 버전 관리 체계의 변경이 실제로 어떤 차이를 만들지 않을 것이라고 생각합니다. 보다 생산적인 경로는 현대화 문제를 해결하는 것입니다. @khinsen 주요 프로젝트의 업데이트를 수락하는 방법을 알고 있습니까? 그렇다면 우리가 당신을 도울 수있는 방법을 찾아야한다고 생각합니다.

다음에서 프로젝트를 업데이트하려고합니다.
https://github.com/ScientificPython. Python 코드를 업데이트해야합니다.
이전 C API를 사용했습니다 (그리고 이전을 의미합니다. Py_PROTO와 같은 일부 기능은
2000 년부터). 물론 PR도 환영하지만
시간을 보내고 싶어합니다.

그가 제기 한 더 큰 문제는
프로젝트 "(모든 프로젝트가 정확히 어디에 있는지 모르겠습니다.
업데이트가 필요한 Python 3) 지원을 보았습니다. 어때?
NumPy 개발자 시간이 할당 된 프로젝트를 결정 했습니까? 그리고 나는
그의 핵심 주장이 유효하지 않다고 생각하지 마십시오. SciPy는
이전 포트란 프로젝트 (예 :
fftpack) 수정이 거의 또는 전혀 없습니다. 이것들이 말로 쓰여졌다면
"fortran 2"와 새로운 컴파일러는 "fortan 3"만 컴파일했습니다.
중요한 문제였습니다.

즉, 이러한 문제는 실제로 NumPy의 잘못이 아닙니다. 그가 가진 것에도 불구하고
NumPy 1.13이 설치된 상태에서 oldnumeric은 여전히 ​​모든 테스트를 통과했습니다.
NumPy가 여기서 범인이 아님을 나타냅니다. oldnumeric API는
말 그대로 10 년이 넘었습니다 (아마 20 년이 다가옴!).
최신 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는 항상 1 명의 유지 보수 자 + 때때로 기여자 프로젝트로 남아 있습니다. MMTK에 의존하는 대부분의 코드가 완전히 유지되지 않기 때문에 모든 MMTK를 "현대적인 SciPy"로 포팅하는 것이 누구에게도 좋은 결과를 가져다 줄지 확신 할 수 없습니다. 그러나 내 주변에서 보는 대부분의 Python 코드, 심지어 MMTK와 완전히 관련이없는 코드도 마찬가지입니다. 계산과 코딩이 아닌 실험이 관심의 초점에있는 연구 영역의 현실입니다.

@xoviat oldnumeric 의 테스트 수는 엄청나게 적습니다. 나는 그들이 NumPy 1.13을 통과한다는 사실에서 많은 결론을 내리지 않을 것입니다.

지금까지 살펴본 C 확장 모듈은 말 그대로 20 년이 지났으며 Python 1.4 용으로 작성되었습니다. 그 당시에는 Python-C 콤보의 가장 정교한 예 중 하나였으며 실제로 Numeric (pre-NumPy) 및 CPython 자체의 초기 개발을 형성했습니다. .

저는 오늘의 API와 지원 도구가 훨씬 더 우수하다고 처음으로 말했으며 앞으로도 계속 개선 될 것으로 기대합니다. 그러나 어떤 사람들은 그것이 아무리 구식이든 상관없이 단순히 소프트웨어를 사용하여 연구를 수행하기를 원하며 그들도 존재할 권리가 있다고 생각합니다.

@rgommers 사용자가 버전 번호를 볼 수 없다는 주장을 무시하지 않습니다. 사람들이 내 주변에서 사용하는 환경에서는 사실이 아닙니다. 업데이트를 결정하는 사람들 (항상 최종 사용자는 아님)은 업데이트를 봅니다. 그들은 단지 일주일에 한 번 "pip install --upgrade"를하지 않습니다. 그들은 심지어 이것을 부주의 한 태도라고 생각할 것입니다.

주변 사람들이 주로 Windows에서 Anaconda를 사용하는 경우 이는 우리가 매우 다른 환경에서 작업한다는 것을 확인하는 것입니다. 다양성의 시대에 각 커뮤니티가 잘 작동하는 도구와 규칙을 채택 할 수 있다는 데 동의 할 수 있기를 바랍니다.

그리고 예, NodeJS는 더 나쁩니다. 동의합니다. 다행히도 쉽게 무시할 수 있습니다.

이 스레드를 팔로우하지만 감히 들키지 않는 동료로부터 전자 메일을 받았습니다. 뛰어난 비유로 :

"새 현미경을 사서 더 나은 과학을 할 수있는 기회가 생기면 정말 마음에 듭니다.하지만 누군가 저와상의하지 않고 하룻밤 사이에 제 현미경을 교체하는 모습을보고 싶지 않습니다."

그것은 모두 자신의 도구를 제어하는 ​​것에 관한 것입니다.

나는 한밤중에 당신 동료의 실험실에 침입하여 그들의 numpy를 업그레이드하지 않을 것이라고 약속합니다. 나는 발라 클라 바도 가지고 있지 않다.

업데이트를 결정하는 사람들 (항상 최종 사용자는 아님)은 업데이트를 봅니다. 그들은 단지 일주일에 한 번 "pip install --upgrade"를하지 않습니다. 그들은 심지어 이것을 부주의 한 태도라고 생각할 것입니다.

시스템 관리자이고 다양한 설치 방법의 장단점을 이해하고 있다면 Python 세계 (및 엄격한 semver를 사용하지 않는 다른 많은 소프트웨어 프로젝트)에서 버전 관리가 어떻게 작동하는지 실제로 이해 (또는 교육)해야합니다.

현재 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.7이 누락 된 경우 제외) Linux 가 1.6으로 돌아가는 것 같습니다 .

MacOS / Linux 상황은 꽤 합리적입니다. 더 많은 Windows 릴리스를 채울 수 있을까요? Windows의 OTOH pip install 은 (는) 영웅적인 노력 없이는 일한 적이 없었기 때문에 이에 대한 많은 청중이 있는지 잘 모르겠습니다. 우리는 이미 2 년의 가치가 있으며 시간이 지남에 따라 성장할 것입니다.

또한 우리가 오래된 바퀴를 마지막으로 업로드했을 때 누군가가 그들의 작업 흐름이 바퀴가 없다고 가정하고 이전 버전과의 호환성을 깨뜨 렸기 때문에 우리에게 화를 냈습니다 :-)

그 이야기를 듣고 싶습니다.

내가이 부분을 잘 알고 있다는 것은 아니지만 개선을 시도 할 수 있다고 생각합니다 (그게 무슨 뜻인지 잘 모르겠습니다!). 사실은 천천히 진행해야합니다. 소수의 사람들의 코드를 깨는 것을 의미했습니다. 마이너 릴리스는 "거의 모든 사람들이 아무것도 알아 차리지 않고 업데이트하고 업데이트 할 수 있어야한다"는 의미라고 생각하며 솔직히 그게 사실이라고 생각합니다. (분명히 정수 비추천과 같은 많은 사람들에게 영향을 미치는 요소가 있지만 잘못된 결과를 생성하지 않고 오래 지속되었습니다)

솔직히 어떤 것이 될지 확실하지 않지만 메이저 버전을 증가시킬만큼 큰 변화가 있었을 수도 있다는 것을 알 수 있습니다. 그리고 네, 아마도 메이저 릴리스와 관련하여 역사적인 모멘텀 손실이있을 수 있습니다.

어쨌든 나는 또한 (거의) 모든 릴리스가 주요 릴리스라고 말하는 팬이라고 말할 수 없습니다. 나는 우리가 약간의 변화로 사람들을 화나게 할지도 모른다는 것을 알지만, 나는 다소 광범위한 변화에 참여했고, 그것이 옳은 일이라고 들었을 뿐이라는 이유를 설명하고 매번 우리는 기다렸다. 이러한 변경 사항이 적용될 때까지 몇 년이 걸립니다.

예를 들어, 컴파일 / C ++에 대해 많이 알지 못합니다. gcc 4.8 정도에 짜증이 나서 일부 C ++ 11 기능 때문에 플래그를 올바르게 변경하는 방법을 알아 내도록 강요하기 시작했습니다. 그래서 기대되는 것은 당신이 numpy에 대해 얻는 것처럼 보이는 이메일에 매우 유사한 반응을 유발하므로 그다지 다른지 확신하지 못합니다. :).

어쨌든, 여기서 너무 많이 논의하고 싶지는 않습니다. 너무 빠르거나 충분히 조심하지 않는지에 대한 피드백에 감사드립니다.하지만 주 버전을 변경하는 것이 많은 도움이 될 것 같지는 않다는 것을 인정해야합니다. 그. 개인적으로 나는 1.13과 1.6이 어떤 의미에서 적어도 하나의 메이저 버전이라고 생각하지만, 그 사이에 내가 가리키고 말할 수있는 단일 릴리스는 없습니다. 이것은 많은 사용자에게 주요 호환성 중단이었습니다.
나는 코드에서 "Lets do this in Numpy 2 아마도"라는 주석을 읽은 기억이납니다. 정확히 어떤 것이 든 깨지는 것에 대한 두려움 때문입니다. 그 접근 방식을 사용하면 numpy가 많이 멈췄 을까 봐 두려워요. 솔직히 저는 일부가 된 것을 자랑스럽게 생각합니다. 나에게 적어도 다시 더 활동적인 단계처럼 보였고, 우리가 더 보수적 이었다면 힘들었을 것입니다. (내가 오기 전에 무슨 일이 일어 났는지 잘 모르기 때문에 편향되어있을 것입니다. :)).

죄송합니다. 이건 말이 안 돼요 (방금 크리스마스 파티를 했어요) semver 제안은 말이되지만 실제 해결책처럼 느껴지지 않는다는 것을 인정해야합니다. 나는 더 적극적으로 메이저 버전을 올리는 것에 동의 할 수 있지만, 기본적으로 모든 릴리스를 메이저 릴리스라고 부르는 것에 동의하지 않습니다. 나는 또한 어떤 경우에는 좀 더 보수적이 되려고 노력하는 것에 동의 할 수 있지만, 솔직히 그게 뭔지 확실하지 않습니다 (어딘가에서 호환성을 깨뜨릴 수 있는지 아무도 확실하지 않기 때문에 매달린 PR의 수를 세어보세요.). 좋은 부분입니다)?

그리고 내가 불평을 읽더라도 약간의 도청과 주장을 가져 오면 합리적으로 가능하다면 모든 변경을 취소하지 않거나 적어도 1 년 이상 지연시키지 않는 것과는 다릅니다. 우리가 보수적 거버넌스 모델을 선택한 이유의 일부라고 말하고 싶습니다….

그래서 오랫동안 옹알이를 한 후 :

• "거의 아무도 코드가 깨지지 않는다"는 마이너 버전에서는 괜찮은 것 같습니까?
• 천천히 전진해야하나요?
• 결국 상황이 깨질 것이고 때로는 메이저 버전을 늘릴 수도 있습니다. 아마도 메이저 버전에서 더 많이 변경되는 FutureWarning 유형을 시도 할 수도 있습니다. (솔직히 그것이 도움이 될 것이라고 믿지 않지만 기꺼이 노력할 것입니다)

가장 중요한 것은 좌절감을 알고 있지만 우리에게 진정한 해결책이 있습니까? 우리가 주 버전을 공격적으로 올리면 더 적은 이메일을받을 것이라고 생각하십니까?

@xoviat 이전 버전의 휠 업로드에 대한 불만 사항에 대한 이야기를 요청하고 있습니까? 그것은 # 7570이었습니다.

내가 가장 좋아하는 semver 정의 (원래 게시물에 대한 링크를 더 이상 찾을 수 없음) :

• major : 의도적으로 사용자 코드를 위반했습니다.
• 경미 : 실수로 사용자 코드를 위반했습니다.
• 패치 : 우리는 마지막 마이너 릴리스의 버그에 대한 사용자 해결 방법을 깨뜨 렸습니다.

약간 건방진하지만 수입품에 대한 히트는 _any_ 행동의 변화가 일부 사용자를 어딘가에 망가뜨릴 것이라고 생각합니다. 이는 API 표면이 큰 프로젝트에서 특히 그렇습니다.

제 생각에 첫 번째 단계는 특정 설치의 변경 속도에 대한 제어권을 개발자에서 최종 사용자에게 더 가까운 사람으로 전환하는 것입니다.

이 대화에서 빠진 점은 이전 버전의 라이브러리가 항상 사용 가능하다는 것입니다 (소스의 pypi에서). 따라서 이전 버전의 python / numpy / matplotlib가 필요한 코드가 있으면 이전 버전을 사용하십시오. 사용자 공간 환경은 이것을 관리하기에 너무 끔찍하지 않게 만듭니다.

새 버전의 라이브러리를 사용하려면 변경 사항을 유지하는 데 드는 비용을 지불해야합니다. 현미경 비유를 계속하려면 현미경을 정기적으로 유지 관리해야합니다. 그렇지 않으면 시간이 지남에 따라 성능이 저하됩니다. 소프트웨어도 다르지 않습니다.

@njsmith 꽤 재밌 네요. IMO # 7570은 유효한 문제가 아닙니다.
NumPy는 manylinux wheel 사양을 준수했습니다. 일반적으로 바퀴
시간이 무료라는 가정하에 이전 버전 용으로 업로드해야합니다. 주어진
시간은 자유롭지 않습니다. 사람들이 바퀴를 만들 수 있다는 것을
원하는 경우 특정 버전의 NumPy를 위해; PR 제출
numpy-wheels 저장소. 아님.

@xoviat 내 말은, 그들의 시스템이 고장

@njsmith 현미경 비유에서 귀하의 역할은 내 동료의 실험실 책임자에게 접근하여 모든 실험실 현미경을 그의 최신 모델로 교체하고 작은 글씨에 "1mm 이상의 샘플과 호환되지 않음"이라는 문장을 숨기는 제안을하는 현미경 판매원의 역할입니다. 계약의. 이로 인해 랩 디렉터는 이러한 세부 사항을 이해하는 사람들과 논의해야 할 기술적 요점이 있음을 이해하기가 매우 어렵습니다.

@rgommers 나는 NumPy를 유지하는 것이

다른 한편으로, 나는 매우 특별한 안경 세트를 가지고 있음을 확실히 인정하지만,이 토론에서 다른 모든 사람들에게 해당됩니다. 제 안경은 제 작업 환경 인 "전통적인 과학 컴퓨팅"의 안경입니다. 기준 (기본 기대)은 업데이트가 의도적으로 어떤 것도 손상시키지 않는다는 것입니다. 이것이 표준화 된 언어 (C, Fortran)의 정책이지만 인프라 라이브러리 (BLAS, LAPACK, MPI, ...)의 정책이기도합니다. 그럼에도 불구하고 혁신은 발생합니다 (예 : ATLAS). 그것이 보수적이라고 생각한다면, 내 세계에서 보수적 의미가 무엇인지 설명하겠습니다. 대부분의 버그가 알려져 있는지 확인하기 위해 적어도 2 년이되지 않은 버전은 설치하지 마십시오. 이는 시간이 매우 비싸고 그 이유 때문에 결과를 거의 확인할 수없는 슈퍼 컴퓨터에 대한 일반적인 정책입니다.

NumPy가 내 세계의 기본 기대치를 채택해야한다고 말하는 것이 아닙니다. 나는 단지 그것이 다르다는 것을 분명히 나타내야한다고 말하는 것입니다.

@seberg "거의 아무도 코드가 깨지지 않는다"는 이론상 부 버전의 경우 괜찮아 보입니다. 그러나 소프트웨어가 인프라 상태를 획득하면 (내 생각에는 NumPy가 해당 수준에 있음) 영향을받을 수있는 개발자와 사용자 수를 추정하는 것은 불가능합니다. 그러면 기준은 항상 "내가 생각할 수있는 사람은 거의 영향을받지 않는다"가되며 이는 좋은 기준이 아닙니다.

@tacaswell 저는 "

음, 솔직히 "주요 재개발"아이디어는 훨씬 더 많은 개발 능력을 필요로하고 완전히 다른 유형의 혼란을 만들 수 있기 때문에 현재 거의 포기되었다고 생각합니다 (처음 몇 년 동안 py2 및 py3 참조)?

동의, numpy는 인프라이지만 더 많은 사람들의 코드를 깨는 것이 괜찮은 것처럼 행동하는 팬이 아닙니다. "아무도 코드가 깨지지 않는"릴리스 ( "몇 번의 릴리스에 대한 경고를 보지 않은 경우"예외)를 수행하기 위해 최선을 다하는 작업을 포기하고 실제로 결정에 도움이되는 것 같습니다. 업데이트.

그래서 때때로 우리는 그것이 사실이 아닐 수도 있다는 것을 인정해야 할 것입니다. 그렇지 않으면 우리가 더 이상 깨지지 않도록 해결책을 얻는 것을 훨씬 선호합니다. 물론 당신은 해결책을 제시했지만 (매우 보수적이며 대대적 인 정비를 통해 numpy 2를 시작합니다),이 해결책이 큰 자금 없이는 실현 불가능하다는 것을 인정하면, 우리는 다른 무엇을 할 수 있습니까?

또는 명확하게 말 해주세요 : 필요할 때 더 보수적 인 사람이되기 위해 주시 할 수있는 numpy dev를 팔로우 할 수있는 사람을 알고 있다면 적어도 감사합니다. 그러나 저는 개인적으로 미래의 개발을 위해 numpy의 더 어두운 모서리를 천천히 제거하는 우리의 진행을 포기하는 것을 감사하지 않습니다. 기껏해야 몇 년 안에 죽은 NumPy와 교체로 끝날 것입니다. 최악의 경우 우리는 앞으로 나아갈 수없고 아마도 "대체"가 돋아나게 될 수 있다는 점에 실망하고 다운 스트림에 좌절하게 될 것입니다. 거의 성숙하지 않으면 상황이 악화됩니다.

다른 네임 스페이스를 만드는 것에 대해 @seberg 와 동의해야합니다. 그만큼
이 아이디어의 전체적인 가정은 NumPy 프로젝트가
모두를 위해 일하는 도서관을 유지하기위한 재능과 자원.
그러나 그것은 사실이 아닙니다. 개발자는 완벽하지 않으므로 일반적으로
처음으로 잘못 이해하십시오. 원래 숫자 코드를 작성하는 사람들
사용되는 모든 시나리오를 예측할 수 없었고
PyPy와 같은 대체 구현의 등장을 예측할 수 없었습니다.

API 안정성이 매우 중요하다고 생각합니다. 나는 또한 NumPy가 가지고 있다고 생각합니다
일반적으로 옳았습니다. 문제의 사실은 NumPy가 이미
추론하기가 어렵습니다.
성능이 중요 함),하지만 다른 네임 스페이스를 만들면
코드 변경의 모든 의미를 유지하기가 매우 어렵습니다.
너의 머리. NumPy가 그렇게했다면
개발자가 이해하지 못하기 때문에 훨씬 더 많은 버그가
한 인터페이스에서 다른 인터페이스로 코드 변경의 결과.

요약하면 사람들의 좌절감을 완전히 이해합니다. 하지만 @njsmith로
모든 사용자를 만족시킬 문제에 대한 해결책은 없습니다.
대부분의 사용자를 만족시킬 수있는 유일한 솔루션이 있습니다. 과
현실은 NumPy가 소수의 사용자 (
경멸적인 방식으로) 다른 모든 것보다 API 안정성을 요구했습니다.
NUMFOCUS 자금은 돈이 무엇인지 명확하지 않기 때문에 고갈 될 수 있습니다.
사용되었습니다. 그러면 우리는 어디에 있습니까? 아마도 다음과 같은 상황에서
MMTK는 더 이상 NumPy에 의존 할 수 없습니다.
더 이상 숫자에 의존하지 않습니다.

현재 코드를 최소 유지 관리 모드로 설정하고 다른 네임 스페이스에서 대대적 인 재 설계를 시작하여 버퍼 인터페이스를 통해 이전과 새가 상호 운용성과 무기한 공존하도록했습니다. 그리고 예, 저는 이것이 여러 가지 이유로 사소한 노력이 아니라는 것을 알고 있지만 축적 된 기술 부채 더미에서 벗어날 수있는 유일한 방법이라고 생각합니다. 재 설계의 주요 목표는 유지 관리입니다.

나는 실제로 당신과 동의하지만 자금 / 비전의 큰 주입 없이는 그것이 어떻게 실현 가능한지 모르겠습니다. NumPy는 거대한 작업을 구성합니다. 아마도 @teoliphant 와 @skrah 는 낼 것이지만 그것은 힘든 전투가 될 것입니다.

오늘 우리가 가지고있는 NumPy를 감안할 때, 우리가 합리적으로 할 수있는 것만 큼 잘하고 있다고 생각합니다.

"예"라고 답한 사람들에게 두 번째 질문입니다. 이렇게 한 적이있는 numpy 이외의 소프트웨어 이름을 지정할 수 있습니까?

django는 시맨틱 버전 관리를 사용하지 않는 또 다른 주목할만한 소프트웨어입니다. 그들은 상당한 중단을 나타 내기 위해 주요 변경 사항을 사용하지만 장기간의 경고 후에 .x 변경 사항을 더 이상 사용하지 않습니다. NumPy와 비슷합니다.

나는 실제로 당신과 동의합니다.

@shoyer 관심이

이것이 표준화 된 언어 (C, Fortran)의 정책이지만 인프라 라이브러리 (BLAS, LAPACK, MPI, ...)의 정책이기도합니다. 그럼에도 불구하고 혁신은 발생합니다 (예 : ATLAS).

LAPACK / ATLAS / OpenBLAS의 속도에 따른 혁신은 NumPy가 다른 것보다 훨씬 더 빨리 무의미 해지는 비결입니다.

이 버전 변경이 일어나지 않을 것이라는 모든 응답을 통해 여러분에게 분명해야합니다. 그것은 ~ 7 명의 활성 코어 개발자와 주요 다운 스트림 프로젝트의 일부 개발자 간의 합의입니다. 절대적인 안정성이 필요한 경우 몇 년 동안 시스템에 고정 버전을 고정하고 시스템 관리자에게 이에 대해 교육하는 것이 가장 좋습니다.

언젠가는 새로운 코드베이스로 매우 고통스러운 py3k와 같은 전환이되지 않을까요?

가장 큰 차이점은 Python 3이 (Python 프로그램의 경우) all / nothing 스위치 인 반면, 다른 ndarray 라이브러리를 혼합 / 매치하는 것은 쉬우거나 적어도 할 수 있다는 것입니다. 버퍼 인터페이스는 복사본없이 데이터를 앞뒤로 전송할 수 있음을 의미합니다. np.asarray() 를 사용하여 함수에 입력을 강제하면 다른 유형의 배열을 반환하기 위해 스위치로 작업하는 일부 라이브러리를 알지 못할 수도 있습니다.

이것은 숫자 / numarray / numpy의 반복되는 부분처럼 들립니다.
별로 즐겁지 않은 경험이었습니다 (버퍼 인터페이스는
하지만 그러한 전환에는 여전히 수동 코드가 필요하다고 생각합니다.
모든 것이 사소한 것은 아닙니다.) 그것은 또한 불가능합니다
Scipy와 같은 라이브러리가 "새 어레이"없이 "업그레이드"
이전 버전과의 호환성을 깨기 때문에 문제는
다른 도서관이 유사한 결정을 내 리도록 강제합니다.
오래된 네임 스페이스를 버리십시오.

모든 사람이 np.asarray 입력을 강요했다면 np.matrix 는 문제가되지 않습니다 :-).

다른 배열 라이브러리가 duck 유형에 동의 할 수 있고 버퍼 프로토콜이 표현할 수있는 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이고 그게 문제입니다.

예, 그것은 파이썬 습관의 큰 휴식입니다. 그리고 예, 그 위에 연산자를 구현하는 것은 까다로울 것입니다. 하지만 할 수 있다고 생각하고 노력할만한 가치가 있다고 생각합니다.

내가 물건을 깨는 데 찬성 할 수 있음을 보여주기 위해 ;-)

@rgommers 내가 쓴 글을 다시 읽으십시오. 반복하지 말고 NumPy가 LAPACK의 속도를 채택해야한다고 제안하지 않습니다.

나는 이해. 내 답장의 두 단락은 직접적인 관련이 없습니다. 혼란 스러우면 죄송합니다.

나는 그것이 그렇게 기대하지 않는 사람들 (즉, 내 환경에있는 사람들의 80 %)을 가진 사람들에게 분명하게 신호를 보낼 것을 제안합니다.

그것이 내가 말한 것입니다. 당신의 제안이 거절 될 것이라는 합의가있는 것 같습니다. 80 %에 고정 된 버전을 요청하고 그 이유를 설명하기 만하면됩니다.

@khinsen OK, 그럼 내 예가 가능하다면 확실히 만들 수있는 인덱싱의 호환되지 않는 변경 인 척하십시오. (멋진 인덱싱에는 매우 혼란스러운 코너 케이스가 있습니다.)

@njsmith 같은 문제가 있습니다. 인덱싱은 Python의 메서드 호출이므로 다시 OO입니다.

부수적 인덱싱은 NumPy에서 가장 큰 디자인 실수입니다. 왜냐하면 그것은 분명한 사양을 가지고 있지 않았기 때문입니다. 정수 인수의 경우 np.take np.repeat , 부울 인수의 경우

실제로이 스레드의 주제와 관련이 있습니다. 왜냐하면 이것은 개발이 너무 빨리 진행될 때 발생하는 디자인 실수의 종류이기 때문입니다.

나는 사람들에게 그것을 사용하지 말라고 전적으로 SciPy 코스에서 멋진 인덱싱에 대해 논의합니다. np.take 및 np.repeat 가 완벽하게 잘 작동하고 문제를 일으키지 않습니다. 그리고 메소드가 아닌 함수로 사용하면 OO 문제도 없습니다. 이름이 부울과 함께 사용될 때 의도를 암시하지 않기 때문에 np.repeat 을 싫어하는 사람들을 위해 별칭을 도입하십시오 : select = np.repeat . 다시 한 번 OO가 불필요하게 어렵게 만들었습니다.

일반 인덱싱은 이러한 문제의 영향을받지 않습니다. 가능한 모든 상황에서 거의 모든 사람들이 기대하는 일을 수행하므로 메서드로 구현할 수 있습니다.

내 관점에서 볼 때 까다로운 문제는 산술입니다. np.add(a, b) 대신 배열 추가를 위해 a+b 를 작성하고 싶지만, 특히 결과 dtype 측면에서 정확히 a+b 이 수행해야하는 작업에 대한 보편적 인 합의가 없습니다. . 그것은 Numeric / numarray 분할의 핵심 문제 중 하나였으며, NumPy에 새로운 스칼라 유형이 도입되었으며, 이로 인해 불쾌한 놀라움도 상당히 많이 발생합니다. 나는이 문제가 해결 될 수 있다고 믿지만 GitHub 문제 논의에 대한 부수적 인 발언은 아니다.

@rgommers "80 %에 고정 된 버전 요청"이 가능했다면 오래 전에 해왔을 것입니다. "80 %"는 대화 할 수있는 조직화 된 커뮤니티가 아닙니다. 배경 문화를 공유하지만 서로 상호 작용하지 않는 많은 사람들입니다. 귀하의 제안은 "Windows 사용자에게 Linux로 전환하도록 요청"(또는 그 반대)과 비슷합니다.

이것이 NumPy가 인프라 소프트웨어라고 주장함으로써 제가하려는 요점입니다. 많은 사람들에게 소프트웨어 설치를 구성하는 것은 수백 개의 레고 브릭 중 하나 일뿐입니다. 그들은 그것에 대해 특별히 신경 쓰지 않고 단지 거기에 있고 "일"하면됩니다.

나는 이것을 너무 많이 탈선시키고 싶지 않지만 np.repeat 및 bool 배열로 무엇을 언급하고 있는지 전혀 모릅니다.

@ eric-wieser는 0 번 반복하고 배열에서 제거하면 1 번 유지됩니다. 나는 인덱싱 대신 이것을 가르치는 것에 동의하지 않습니다 . 당신이 그것을보고 싶다면 나열하지만 ...).

이것은 더 이상 아무데도 가지 않기 때문에 사이드 포인트입니다 :). 나는 실제로 numpy에서 천천히 고치는 것이 미래의 어느 시점에서 numpy를 더 쉽게 교체 할 수 있도록 약간 희망합니다.

귀하의 제안은 "Windows 사용자에게 Linux로 전환하도록 요청"(또는 그 반대)과 비슷합니다.

흠, 기술적으로 유능한 사람들에게 실제 세계의 버전 번호가 실제로 어떻게 작동하는지 알아 보도록 요청하는

이것이 NumPy가 인프라 소프트웨어라고 주장함으로써 제가하려는 요점입니다.

그리고 아마도 우리가이 전환을한다면 SciPy가 다음 인프라이기 때문에 SciPy로 넘어갈 것입니까? 언제 인프라가 중단됩니까? 그리고 NumPy와 다른 인프라가 Python 자체 및 나머지 전체 과학 Python 생태계와 완전히 다른 버전 관리 체계를 원하는 이유는 무엇입니까?

80 % "는 대화 할 수있는 조직화 된 커뮤니티가 아닙니다.

당신이 사용하는 슈퍼 컴퓨터의 관리자는 정말로 서로 대화해야합니까? 이 두 시스템에서 모든 업데이트 소프트웨어를 돌아 다니며 이야기하지 않는 사람들이 많을 수는 없습니다. 전 세계 모든 시스템 관리자의 80 %를 교육해야한다는 의미가 아니라 필요한 사람 만 교육해야합니다.

@seberg 목록과 배열이 인덱싱을 공통 속성으로 만 공유하는 다른 데이터 유형

뿡 빵뀨

당신이 사용하는 슈퍼 컴퓨터의 관리자는 정말로 서로 대화해야합니까?

아니요. 그들은 서로의 존재에 대해서도 알지 못합니다. 그들은 서로 다른 장소에있는 서로 다른 조직을 위해 일하며, 유일한 공통점은 몇 명의 사용자를 공통으로 갖는 것입니다.

전 세계 모든 시스템 관리자의 80 %를 교육해야한다는 의미가 아니라 필요한 사람 만 교육해야합니다.

이것은 나에 관한 것이 아닙니다. 제 자신에게 완벽하게 작동하는 솔루션이 있습니다. 저는 항상 Python과 모든 라이브러리를 홈 디렉토리에 설치합니다.

여기에 관한 것은 제가 협력하는 사람들과 저에게 도움을 요청하는 사람들입니다 (예 : 그들이 과거에 제 Python 과정 중 하나에 참여했기 때문에). 그들은 자신의 Python 설치를 관리하고 다른 사람 (관리자 또는 경험이 더 많은 동료)에게 맡길 수있는 기술적 능력이 없습니다.

실제 버전 번호가 실제로 어떻게 작동하는지 알아보기 위해

내가 생각하는 사람들의 공유 된 배경 문화에서 현실 세계는 실제로 의미 론적 버전 관리 또는 근사치처럼 작동합니다.

내가 생각하는 사람들의 공유 된 배경 문화에서 현실 세계는 실제로 의미 론적 버전 관리 또는 근사치처럼 작동합니다.

그 이유는 LAPACK & co와 같이 대부분 느리게 움직이는 제한된 수의 라이브러리를 사용하기 때문입니다. @njsmith가 지적했듯이 대부분의 소프트웨어는 의미 론적 버전 관리를 사용하지 않기 때문에 버전 번호가 낮습니다.

@rgommers 내가 "작은 숫자"라고 말하지는

@njsmith가 지적했듯이 대부분의 소프트웨어는 의미 론적 버전 관리를 사용하지 않기 때문에 버전 번호가 낮습니다.

내 경험으로는 아닙니다. 그러나 "다수"는 아마도 당신과 저 모두에게 "내가 아는 대부분"을 의미 할 것입니다. 그리고 SciPy 생태계 밖에서 당신이 사용하는 패키지와 내가 사용하는 패키지 사이에 겹치는 부분이 거의 없을 것입니다.

그리고 아마도 우리가이 전환을한다면 SciPy가 다음 인프라이기 때문에 SciPy로 넘어갈 것입니까? 언제 인프라가 중단됩니까?

저는 실제로 SciPy와 SciPy 생태계의 나머지 모든 기본 사항이 동일한 원칙을 채택하는 것을 선호하지만 개인적으로는 NumPy보다 훨씬 더 널리 사용되는 다른 라이브러리와 훨씬 더 근본적입니다. NumPy 배열은 많은 과학 소프트웨어의 중심 데이터 구조 인 반면 SciPy는 주어진 응용 프로그램에서 작은 하위 집합을 사용하는 거대한 함수 모음입니다.

또한 SciPy는 사실상 1.0에 이르렀 기 때문에 의도적으로는 아니지만 의미 론적 버전 관리를 사용합니다.

그리고 NumPy와 다른 인프라가 Python 자체 및 나머지 전체 과학 Python 생태계와 완전히 다른 버전 관리 체계를 원하는 이유는 무엇입니까?

전체 SciPy 생태계는 실제로 과학 컴퓨팅에서 지배적 인 접근 방식 인 동일한 접근 방식을 사용해야합니다. 습관이 다른 다른 도메인의 Python 및 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 : 멋진 인덱싱. 실제로 이것은 전용 기능을 사용할 수 있습니다. 예를 들어 tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask 등과 같이 TensorFlow에서 수행 한 작업입니다. 결과는 [] 오버로드하지만 확실히 더 투명합니다.

도움이 될 수있는 또 다른 기능은 Python 2에서 3으로의 전환의 어려움 때문에 부분적으로 동기를 부여한 기능인 유형 주석입니다.

이것이 쉬울 것이라고 말하는 것이 아닙니다. 내 생각에 커뮤니티 결과는 더 큰 문제입니다. 이것은 실제로 구현하는 데 많은 에너지가 필요하며 SciPy와 같은 프로젝트로 다운 스트림을 푸시합니다.

@khinsen 나는 일주일 내내 토론을 따라

현재 Apple Accelerate 프레임 워크 덕분에 필요한 최소 LAPACK 버전은 10 년 이상 전의 3.1.ish입니다. 그리고 현재 LAPACK은 3.8.0입니다. 그 동안 그들은 꽤 많은 루틴 (더 이상 사용되지 않거나 제거됨)을 버리고 많은 버그를 수정했으며 가장 중요한 것은 상용 소프트웨어와 Python 과학 소프트웨어 간의 격차를 메우는 데 필요한 새로운 루틴을 도입했습니다. 최종 결과는 여기 에 요약되어 @rgommers 와 다른 사람들을 주로 성가 시게

이제 최신 버전에 대한 확실한 요구가 있습니다. 그것은 논의가 아니며 우리는 그 부분을 안전하게 건너 뛸 수 있습니다. NumPy 및 SciPy의 사용자 중 상당 부분이 이로 인해 혜택을 볼 수 있습니다. 그러나 우리는 당신이 이미 제시 한 논쟁 때문에 단순히 그것을 버릴 수는 없습니다. 이 문제를 어떻게 해결 하시겠습니까?

나는 비열한 방식으로 이것을 묻는 것이 아니라 모든 개발자가 똑같이 생각하기 때문에 (그리고 나는 그들과 동의한다고 말해야 함) 아마도 당신의 외모가 신선한 아이디어를 줄 수 있습니다. Accelerate를 유지하고 그러한 일이 발생할 때마다 새로운 NumPy / SciPy 패키지를 만들어야합니까? 혁신을 위해 지원을 중단한다면 여기에가는 가장 좋은 방법은 무엇입니까?

현재 Apple Accelerate 프레임 워크 덕분에 필요한 최소 LAPACK 버전은 3.1.ish입니다.

@mhvk , 이것은 1,14의 # 9976에서 문제가 될 수 있습니다. 3.2.2가 필요하다고 생각합니다.

@xoviat : 그 문제에 대해이 토론을합시다

@ilayn 구체적이고 건설적인 밀어 주셔서 감사합니다! 사실 그 상황과이 스레드를 시작하도록 동기를 부여한 상황 사이에는 많은 유사점이 있습니다.

주요 공통점 : 서로 다른 요구를 가진 다양한 사용자 / 커뮤니티가 있습니다. 일부는 Accelerate를 원하고 다른 일부는 새로운 LAPACK 기능을 원합니다. 둘 다 특정 우선 순위에 대한 좋은 이유가 있습니다. Accelerate 와 새로운 LAPACK 기능을 모두 원하는 사람들이있을 수도 있지만, 이것은 분명하지 않습니다.

Fortran / C 세계에서는 소프트웨어 스택이 더 얕기 때문에 그러한 문제가 없습니다. 추가 중간체없이 Fortran, LAPACK 및 애플리케이션 코드가 있습니다. 각 애플리케이션 코드는 우선 순위에 따라 특정 버전의 LAPACK을 선택합니다. 컴퓨팅 센터는 일반적으로 여러 LAPACK 버전을 병렬로 유지하며, 각각 자체 디렉토리에 있으며, 애플리케이션 코드의 Makefile 를 수정하여 선택합니다.

SciPy 에코 시스템에서 우리가 이어 받아야 할 교훈은 소프트웨어 버전을 선택하는 것이 소프트웨어 개발자가 아니라 애플리케이션 별 소프트웨어 번들을 조립하는 사람들의 작업이라는 것입니다. 우리 세상에서 그것은 Anaconda, Debian 및 기타 소프트웨어 배포판에서 일하는 사람들뿐만 아니라 다양한 수준의 시스템 관리자와 올바른 능력과 동기를 가진 최종 사용자입니다.

그래서 SciPy / LAPACK 딜레마에 대한 저의 제안은 Accelerate를 사용하여 오늘날의 SciPy를 유지하면서 최소한의 유지 관리 모드 (다른 사람이 인수 할 수 있음)로 설정하는 것입니다. Accelerate를 원하는 사람들은 "SciPy 2017"을 선택하고 행복 할 수 있습니다. 그들은 새로운 LAPACK 기능을 얻지 못할 것이지만 아마도 대부분은 괜찮습니다. 새로운 네임 스페이스 ( scipy2 , scipy2018 또는 기타)에서 개발이 계속되며 최신 LAPACK으로 전환됩니다. 기술적으로 가능하다면이 두 가지 (그리고 미래의) 변형의 병렬 설치를 허용하십시오 (SciPy에서 가능해야한다고 생각합니다). 그렇지 않으면 둘 다 필요로하는 사람들은 여러 환경 (Conda, Venv 또는 Nix 또는 Guix를 통한 시스템 전체 환경)을 사용해야합니다. 이 두 번째 시나리오에서도 모든 수준의 Python 코드 독자가 코드가 작성된 SciPy 버전을 이해할 수 있도록 호환되지 않는 각 변경으로 네임 스페이스를 변경하는 것이 좋습니다.

전체적인 아이디어는 개발자가 새로운 것을 제안하고 개발에 집중하지만 일반적인 의미에서 "더 나은"것으로 광고하거나 보편적 인 대체물로 광고하지 않는 것입니다. 특정 작업에 적합한 소프트웨어 버전 조합을 선택하는 것은 그들의 일이 아니라 다른 사람의 일입니다.

개발과 조립이 서로 다른 사람에 의해 독립적으로 수행된다는 일반적인 생각은 오늘날의 메가 패키지를 서로 다른 속도로 진행할 수있는 더 작은 단위로 분할해야 함을 시사합니다. 오늘날 작은 LAPACK 인터페이스와 f2py 같은 도구를 포함하는 NumPy에 대한 이유가 없습니다. SciPy의 경우 일관성과 공통 개발 정책을 나타내는 공통 네임 스페이스를 갖는 것이 합리적 일 수 있지만 하위 패키지는 독립적으로 배포 될 수 있습니다. 메가 패키지 접근 방식은 20 년 전에 훌륭했던 Python의 "배터리 포함"모토로 거슬러 올라갑니다. 오늘날의 사용자 기반은 너무 다양하며 소프트웨어 패키징은 일반적으로 별개의 활동으로 인식되었습니다. 배터리를 포함하는 것은 이제 Anaconda가 할 일입니다.

이러한 접근 방식을 채택하는 데있어 가장 큰 장애물은 "기계 당 하나의 Python 설치"접근 방식을 사용하는 Debian 또는 Fedora와 같은 전통적인 Linux 배포판입니다. 합리적인 노력으로 여러 시스템 전체의 가상 환경으로 전환 할 수 있다고 생각하지만 이에 대해 많이 생각하지 않았습니다. 저에게 소프트웨어 패키징의 미래는 conda 나 Guix와 같은 환경 기반 시스템입니다.

지금까지 당신이 제시 한 모든 전치사가이 단계들과 어떻게 호환되는지 모르겠습니다.

• 다음 사진의 광기를 재현했습니다.
  
  방금 계산했고 이제 Windows 컴퓨터에 27 개의 복사본이 있습니다. 이제 여기에 릴리스가 더 자주 있기 때문에 10을 곱하고 NumPy 및 SciPy 릴리스주기가 독립적이므로 2를 곱합니다. 2025 년에는 각 라이브러리의 사본 15 개와 LAPACK 10 개, f2py 5 개를 종속성으로 쉽게 만들 수 있습니다. 두 패키지 모두에서 수십 명의 사람들에 대한 유지 관리 부담은 말할 것도없고, 이것은 단순히 작동하지 않을 것입니다. (C ++는 관련이 없으며 모든 표준 라이브러리를 삽입하십시오). Win에 대한 상업용 코드 개발자에게 물어보고 이것이 좋은 생각이라고 말하십시오. 나는 그 교환에서 뒤 따르는 것에 대해 책임지지 않습니다.
• 그런 다음 패키지의 세분성을 높이고 이제는 모두 다른 패키지 버전으로 자체적으로 작업을 수행합니다. f2py는 한 버전에서 무언가를 망쳤으므로 SciPy는 다음 버전에서 빌드를 중지하지만 여전히 이전 버전의 NumPy에 의존합니다. 그래서 일부 전체 론적 실체는 그것들을 무료로 모아야합니다.
• 그런 다음 또한 Anaconda (또는 다른 엔티티)를 Accelerate와 같은 주요 의존 회사로 만들었습니다. 아니면 단순히 "다른 사람"이 풍부 할 것입니다.
• 그런 다음 대부분의 사용자 기반을 가상 환경과 관련하여 실제로 원하지 않는 (자신 포함) 워크 플로로 동원했습니다.
• 그런 다음 통과하는 동안 Linux 운영 체제를 수정했습니다.

아마도 당신은 약간 빗나갔습니다.

(이것은 자유 토론이되었으므로 계속해서 뛰어 들겠습니다).

가속 지원을 유지하는 문제는 최신 LAPACK API가 부족하다는 것이 아닙니다. 그것이 문제라면, 우리는 새로운 LAPACK 심을 배송하고 완료 할 수 있습니다. 문제는 특정 시나리오에서 잘못된 결과를 반환하는 기본 함수가 있다는 것입니다. 우리 자신의 BLAS 함수를 작성하는 것 외에 다른 방법은 없습니다. 그렇게한다면 OpenBLAS 또는 MKL이 필요할 수도 있습니다.

@xoviat 이것들은 모두 https://github.com/scipy/scipy/pull/6051 에서 논의되었습니다

@ilayn 예, 제가 만들고있는 요점에 대해 이미 알고 있습니다. 그러나 코멘트는 @khinsen을위한 것이었다. 저는 그가 Accelerate 지원을 실제로 유지할 수 있다는 인상을 받고 있다고 생각합니다.

Python 생태계의 기능 (또는 제한)은 이름 변경의 끔찍한 해킹없이 라이브러리의 한 버전을 얻는다는 것입니다. 이것은 핵심 Python에서 발생합니다. 이것이 _lib_ 및 _lib_ 2 라는 이름의 라이브러리가 동일한 목적을 가지고 있지만 API 차이가있는 이유입니다. 광석 파이썬조차도 이런 식으로 작동합니다. 누군가가 그것을 찢어서 PyPi에 올리지 않고 현대 파이썬에서 기술적으로 둘 다 사용할 수 있다고하더라도 여러 버전에서 표준 라이브러리를 혼합하는 것은 불가능합니다. 이것에 대한 많은 StackOverflow 질문 이 있으며 모두 동일한 결론을 내립니다.

@ilayn 어떤 이유로 당신의 컴퓨터에있는 모든 버전의 가능한 모든 조합을 원한다면, 예, 그것은 엉망입니다. 하지만 왜 그걸 원 하겠어요? 응용 프로그램 시나리오에 실제로 필요한 조합으로 자신을 제한하면 더 적을 것입니다. 예를 들어, 내 컴퓨터에 정확히 두 개의 Python 환경을 유지합니다. 하나는 20 년 된 코드를 실행하기위한 Python 2 + NumPy 1.8.2를 사용하고 다른 하나는 다른 모든 작업에 대해 약 2 년 전의 최첨단을 나타냅니다 ( 2 년 전에 설정했는데 그 이후로 업그레이드 할 이유가 없었기 때문입니다.)

세분화에 관해서는 아마도 내 제안이 명확하지 않았을 것입니다. 제가 옹호하는 것은 개발 단계가 아니라 포장에서 더 세분화된다는 것입니다. 예를 들어 f2py와 SciPy의 개발이 긴밀한 협력을 계속할 것으로 기대합니다. f2py-2018과 SciPy-2018은 함께 작동해야합니다. 그렇다고해서 단일 개체로 포장되어야한다는 의미는 아닙니다. 목표는 소프트웨어 배포 관리자가 작업을 수행 할 수있는 더 많은 자유를 제공하는 것입니다.

나는 Anaconda 또는 다른 배포판을 종속성으로 만들고 싶지 않습니다. 그것들을 조립하는 것이 많은 작업이라는 점을 감안할 때, 분배의 수가 "풍부하게"증가 할 것이라고 기대하지는 않지만, "다른 사람의 풍부함"과 더 비슷합니다.

"사용자 기반"이 어떤 워크 플로를 원하는지 모르겠습니다. 요구 사항이 다른 다양한 사용자 기반이 많이 있습니다. 개인적으로 저는 여러 환경으로 가고 싶지만 머신 당 단일 환경을 원하는 상당한 사용자 기반이 있다면 일부 배포판이이를 처리합니다. 그러나 가상 환경은 이유 때문에 발명되었으며 실제 문제를 해결합니다. Nix 또는 Guix와 같은 시스템 수준 배포판은 다른 수준으로 이동합니다. 나는 그들이 사라지기를 기대하지 않습니다.

BTW, 실제로 하나의 Linux 배포 (Guix)의 메일 링리스트를 따르고 있습니다. 그다지 재미는 없지만 실제적인 많은 작업이 많습니다. 이런 일을하는 사람들이있어서 기쁩니다.

@xoviat "Keep Accelerate 지원"을 제안하지 않았습니다. 나는 단지 SciPy 변종 (현재 거의 현재 버전)을 박물관의 오래된 릴리스가 아니라 특정 사용자 그룹의 관심 변종으로 유지하는 것이 좋습니다. 문제를 해결하는 것보다 Accelerate를 사용하는 것이 더 중요한 사람들입니다. 다른 사람을위한 창작물을 가속화하십시오. "가장 먼저 가속"하는 사람들은 자신이 선택한 결과와 함께 살아야합니다. 일부 문제는 해결되지 않습니다. 아마 그들에게는 괜찮을 것입니다 ( "알려진 버그가 알려지지 않은 버그보다 낫다"). 왜 그들을 다른 것으로 강제할까요?

라벨링과 커뮤니케이션에 관한 모든 것입니다. 나는 "높은"버전 번호로 표시되는 것처럼 새로운 버전이 "더 나은"것으로 선형적인 진행 경로를 따라 소프트웨어의 이상적인 이미지에서 벗어나고 싶습니다. 이 이미지를 좀 더 현실적으로 생각하는 이미지로 바꾸고 싶습니다. 소프트웨어 릴리스간에 명확한 순서 관계가 없습니다. 오래 지속되는 일관된 개발자 커뮤니티에 의해 생성 된 것은 일시적인 순서가 있지만, 이는 특정 애플리케이션에 대한 품질이나 적합성에 대한 어떤 것도 의미하지 않습니다.

이상화 된 이미지가 맞다면 포크를 볼 수없고 가상 환경도 없을 것입니다. VersionClimber 와 같은 프로젝트도 없습니다.

제가 제안하는 것은 소프트웨어 개발자가이 현실을 부정하기보다는 수용해야한다는 것입니다. 그들은 다양성의 세계를 위해 제품을 개발해야합니다 (그리고 무엇보다도 포장 및 라벨링).

@khinsen 선형 대수 함수의 잘못된 결과가 괜찮다면 계속 가속화 지원을받을 수 있습니다. 그러나 주된 문제는 이것을 원하는 유일한 사람 일 수 있다는 것입니다. 그렇지 않더라도 가속 문제에 대해 누군가 SciPy를 비난하면 어떻게 될까요? 누군가가 케이크를 먹고 싶어하면 어떻게 될까요? 나는 그것이 일어나는 것을 볼 수 있습니다.

@xoviat 아니요, 선형 대수 함수의 잘못된 결과가 좋지 않습니다. 그러나 영향을받는 기능이 전혀 필요하지 않은 SciPy 사용자가 많이있을 것이라고 확신합니다. 언급 한 스레드에서 누군가 Accelerate가 감지되면 영향을받는 기능을 제거 / 비활성화 할 것을 제안했는데, 이는 좋은 해결책이라고 생각합니다 (참고 :이를 구현하는 데 필요한 노력을 판단 할 수 없습니다).

어떤면에서 이것은 메가 패키지 문제의 일부입니다. 보다 세분화 된 배포를 사용하면 개발 및 배포 어셈블리 수준 모두에서 작동하는 것을 선택하는 것이 더 쉬울 것입니다. 예를 들어 HPC 컨텍스트에서 사용하기 위해 서로 다른 하위 패키지가 서로 다른 LAPACK 버전을 사용하는 도메인 및 플랫폼 별 SciPy 배포를 구성하는 배포 어셈블러를 상상할 수도 있습니다.

그러나 영향을받는 기능이 전혀 필요하지 않은 SciPy 사용자가 많이있을 것이라고 확신합니다.

이 진술에 대한 최소한의 증거가 있으며 실제로는 그 반대입니다. 이 기능은 널리 사용되지만 특정 시나리오에서만 실패합니다. 즉, 결과는 정확하지만 정확하지 않을 수 있습니다. 예, OSX를 사용하는 경우 현재 설치 한 SciPy에 적용됩니다. 예, 수정해야합니다.

별도의 브랜치를 유지하는 한, 나는 당신이 유지 보수 할 수 있도록 특정 브랜치에 대한 쓰기 권한을 부여하는 것에 반대하는 사람이 아무도 없을 것이라고 생각합니다. 그러나 이것은 오픈 소스 소프트웨어이며 사람들은 자신이 원하는 것을 작업합니다. 나는 많은 사람들이 그 지점을 유지하는 데 관심이있을 것이라고 회의적입니다.

사실 아나콘다 SciPy는 MKL로 컴파일되어 있으므로이 경우 영향을받지 않을 것입니다. 그렇다면 왜 지원 가속화에 관심이 있습니까?

@xoviat 여기에 큰 오해가있는 것 같습니다. 나는이 특정한 문제에 대해 전혀 개인적인 이해 관계가 없습니다. SciPy의 선형 대수 루틴을 사용하지 않습니다.

당신은 SciPy 문제에 대한 스레드를 가리키고 그러한 상황을 어떻게 처리 할 것인지 물었습니다. 스레드는 단순히 Accelerate 지원을 중단하는 것을 꺼리는 것을 분명히 보여 주며,이 변경으로 인해 영향을받을 중요한 사용자 그룹이 있음을 추론했습니다. 해당 사용자 그룹이 존재하지 않는 경우 어디에 문제가 있습니까? SciPy가 이미 Accelerate 지원을 중단하지 않은 이유는 무엇입니까?

@xoviat 별도의 브랜치를 유지하는 것은 누구에게나 쉽습니다. 동일한 GitHub 저장소에서 호스팅 할 필요가 없습니다. 즉, 분기는 문제가 아닙니다. 문제는 사용자 (및 배포 어셈블러)에게 투명한 개별 SciPy 버전의 병렬 존재를 만들기위한 네임 스페이스입니다.

오늘날, "import scipy"라는 코드를 보면 어떤 범위의 SciPy 버전이 작동해야하는지 알 수 없습니다 (예 : 어느 정도 테스트를 거쳤 음). 가장 좋은 경우에는 "SciPy> = 0.8"또는 이와 유사한 내용의 README가 있습니다. 이 습관은 "상위"버전이 항상 "더 좋으며"어떤 것도 저하 (파괴, 속도 저하 등)하지 않는다는 가정에 기반합니다. 그리고 그 가정은 아주 간단하게 잘못되었습니다.

반면에 코드에 "scipy2017을 scipy로 가져 오기"라고되어 있으면 이전 버전 이나 이후 버전과 함께 사용하면 안 좋은 결과를 초래할 수 있음이 모든 독자에게 분명합니다. 그리고 이전 SciPy 버전이 사라지면 (효과적으로 유지 관리 부족으로) 이러한 코드는 계속해서 불안정하게 작동하지 않고 오류 메시지와 함께 실패합니다.

이것이 제가이 스레드에서 만들고자하는 한 가지 요점입니다. 서로 다른 버전의 공존이 현실입니다. 높을수록 좋다는 생각은 꿈입니다. 다중 버전 우주를 인정하고 오해를 방지하기 위해 모든 사람의 의사 소통을 조정하여 현실 세계를 위해 현실적으로 조직합시다.

글쎄, 몰라… 내 생각에 경고와 관련하여 특정 버전 가져 오기는 경고가 아니며 다른 버전을 사용하는 것은 금지되어 있습니다. 설명하는대로 문제가있는 사용자가 감히 코드를 변경하지 않기 때문입니다. 특정 numpy 버전을 제외한 모든 버전에 대해 테스트되지 않았다는 경고를 설치 / 런타임에 인쇄하면 경고가 발생합니까?

그런 유형의 추가 패키지를 만드는 것이 가능하다고 생각합니다. 나는 또한 그것이 다른 유형의 지옥을 만들 것이라고 기대합니다. 많은 것이 살아남을 수 있지만, 예를 들어 두 가지 버전을 혼합하면 유형 검사가 작동하지 않거나 불가능하므로 기본적으로 시도 할 때까지 작동 할 수 있는지 여부를 알 수 없습니다 (아무도 이것을 테스트하지 않습니다!).
그리고 두 버전을 혼합하도록 제안하지 않는 한 scipy2017 솔루션이 상황을 악화시킬 것이라고 생각합니다. 동적 / 런타임 가상 환경 선택 (파이썬 수준에서 가져 오기 전에 pin_import_version("1.6<numpy<1.10", level="raise") 과 같은)과 같은 것이 더 필요할 것 같습니다.

py2 / py3와 같은 주요 변경 사항이있는 경우 특정 가져 오기가 의미가 있으며 "주요"라인이 표시되는 시간 척도에 대해 다른 의견이 있음을 이미 확인했습니다.

이전 버전과의 호환성 NEP # 11596이 제출되었습니다. 닫을 수 있습니까?

이전 버전과의 호환성 NEP # 11596이 제출되었습니다. 닫을 수 있습니까?

예, 닫을 수 있습니다. NEP (거부 된 대안으로 semver를 명시 적으로 언급 함)와는 별도로 여기서 핵심 개발자의 합의는 semver로 변경하고 싶지 않다는 것입니다. 따라서 wontfix로 닫습니다.

토론 해주셔서 감사합니다.