Numpy: Solicitação: use versionamento semântico

Pode-se considerar que numpy está usando controle de versão semântico, mas com 1 ?

Observe que quase todos os principais projetos científicos Python fazem o que NumPy faz: remove código obsoleto após alguns lançamentos, a menos que seja muito perturbador, e apenas aumente o número da versão principal para, bem, coisas principais.

Não tenho certeza se você está propondo uma mudança na política de suspensão de uso ou se acha que devemos estar na versão 14.0.0 em vez de 1.14.09 agora.

O último: NumPy deve estar aproximadamente na versão 14 agora. Mas eu proponho adotar essa convenção apenas para versões futuras.

BTW: o predecessor do NumPy, Numeric, usou versionamento semântico e chegou à versão 24 ao longo de aproximadamente uma década. Não sei por que isso foi alterado na transição para o NumPy.

Minha impressão é que a grande maioria dos projetos Python não usa versionamento semântico. Por exemplo, o próprio Python não usa controle de versão semântico. (Também não conheço nenhum sistema operacional ou compilador convencional que use o semver - você tem algum em mente?) Concordo que os proponentes do semver fizeram um ótimo trabalho de marketing, levando muitos desenvolvedores a pensar que é um bom ideia, mas AFAICT é essencialmente impraticável no mundo real para qualquer projeto maior do que o botão esquerdo, e eu discuto fortemente a ideia de que o pessoal da Semver agora "possui" o formato MAJOR.MINOR.MICRO tradicional e todos os outros têm que mudar para algo outro.

Você pode dar um exemplo do que entende por "esquema de rotulagem de lançamento que não pode ser confundido com versionamento semântico"? Usando nomes em vez de números? Você cita o versionamento baseado em data, mas o esquema mais comum para isso que eu vi é aquele usado por exemplo, Twisted e PyOpenSSL, que estão atualmente em 17.9.0 e 17.5.0, respectivamente. Essas parecem versões semver totalmente plausíveis para mim ...

E você pode explicar qual benefício isso teria para os usuários? Nesse futuro hipotético, cada lançamento teria algumas alterações importantes que são irrelevantes para a maioria dos usuários, assim como agora. Que informação útil estaríamos transmitindo ao eliminar o grande número a cada poucos meses? "Isso provavelmente quebra alguém, mas provavelmente não quebra você"? Devemos também alterar a versão principal em lançamentos de correção de bugs, dada a inevitabilidade histórica de que uma grande proporção deles quebrará o código de pelo menos 1 pessoa? Você pode dar alguns exemplos de "desenvolvedores de software, usuários de software e gerentes de distribuições de software" que realmente ficaram confusos?

Observe que a lista de e-mails é um local mais apropriado para essa discussão e provavelmente teríamos que discuti-la antes de realmente fazer qualquer alteração, mas os comentários aqui devem ser úteis para ter uma ideia dos tipos de problemas que você deseja para abordar nessa discussão.

@njsmith Parece que o único ponto factual sobre o qual discordamos é se o versionamento semântico é ou não a suposição padrão hoje. Isso requer uma definição mais clara da comunidade em que é (ou não) o padrão. Os níveis de gerenciamento de software que me interessam é o gerenciamento de distribuição e administração de sistemas, que é onde as pessoas decidem qual versão é mais apropriada em seu contexto.

A investigação informal que me levou à conclusão de que o versionamento semântico é o padrão consistia em conversar com administradores de instalações de computação científica. Eu também imaginei
uma abordagem mais empírica (listando os pacotes em uma instalação recente do Debian e escolhendo alguns deles aleatoriamente para investigar sua abordagem de versionamento), mas isso acabou sendo muito difícil, porque poucos projetos afirmam claramente se eles usam versionamento semântico ou não.

Um comentário de um administrador de sistemas particularmente me pareceu relevante: ele disse que para o propósito de decidir qual versão instalar, qualquer convenção diferente de versionamento semântico é inútil. Os administradores de sistemas não podem explorar cada pacote em detalhes (falta-lhes tempo e competência) nem consultar todos os seus usuários (muitos deles). Eles têm que adotar uma política uniforme, e isso tende a se basear na suposição de versionamento semântico. Por exemplo, um administrador de um cluster de computação me disse que verifica alguns "usuários avançados" que conhece pessoalmente antes de aplicar uma atualização com uma alteração no número da versão principal.

Quanto a exemplos de pessoas que realmente ficaram confusas, especificamente no que diz respeito aos usuários científicos do Python, tenho muitos deles: colegas de trabalho, pessoas que encontro em conferências, pessoas que pedem conselhos por e-mail, alunos em minhas aulas. Normalmente começa com "Eu sei que você é um especialista em Python, pode me ajudar com um problema?" Esse problema acaba sendo um script que funciona em um computador, mas não em outro. A maioria dessas pessoas não considera os problemas de dependência, mas alguns realmente compararam os números de versão das duas instalações, encontrando apenas "pequenas diferenças".

Como @ eric-wieser e @rgommers observaram, meu pedido é quase sinônimo de solicitar o "1" inicial ser eliminado das versões NumPy. Em outras palavras, o NumPy de fato já usa versões semânticas, embora não seja o resultado de uma decisão política e, portanto, provavelmente não é feito com rigor. No entanto, isso sugere que o NumPy poderia adotar o controle de versão semântico quase sem alterar o fluxo de trabalho de desenvolvimento atual.

Um comentário de um administrador de sistemas particularmente me pareceu relevante: ele disse que para o propósito de decidir qual versão instalar, qualquer convenção diferente de versionamento semântico é inútil.

Infelizmente, o versionamento semântico também é inútil para isso :-(. Não quero dividir os cabelos ou exagerar; eu entendo totalmente que é um problema real. Mas só porque um problema é real não significa que ele tenha uma solução. Você fundamentalmente não pode resumir a pergunta "devo atualizar este software?" A uma simples verificação mecânica. É uma fantasia. Projetos que usam o semver regularmente fazem versões importantes para as quais todos os seus usuários deveriam atualizar imediatamente e fazer alterações significativas em pequenas lançamentos.

Os administradores de sistemas não podem explorar cada pacote em detalhes (falta-lhes tempo e competência) nem consultar todos os seus usuários (muitos deles). Eles têm que adotar uma política uniforme, e isso tende a se basear na suposição de versionamento semântico. Por exemplo, um administrador de um cluster de computação me disse que verifica alguns "usuários avançados" que conhece pessoalmente antes de aplicar uma atualização com uma alteração no número da versão principal.

Eu gosto dessa parte :-). Duvido que concordemos sobre a filosofia do semver, mas é muito mais fácil ter uma discussão sobre os efeitos concretos de diferentes esquemas de controle de versão e qual resultado achamos mais desejável.

Não acho que o conceito de semver tenha muito a ver com essa política - o administrador do sistema com quem você conversou verifica cada projeto para ver se eles estão usando o semver? A maioria dos projetos não, como você disse, é difícil até dizer quais são. E a política é a mesma que os administradores de sistemas vêm usando desde muito antes de o semver existir. Acho que uma melhor caracterização dessa política seria: "seguir a recomendação do projeto sobre o quão cuidadoso deve ser uma atualização", junto com a tradição antiga de que os lançamentos principais são "grandes" e os lançamentos secundários são "pequenos".

A recomendação do projeto NumPy é que os administradores de sistema devem atualizar para novos lançamentos de recursos, então o que eu deduzo dessa anedota é que nosso esquema de numeração atual está comunicando com precisão o que queremos, e que mudar para semver não ...

@njsmith OK, vamos nos afastar da filosofia e

Mais uma vez, parece que temos uma grande diferença de opinião aqui. Para você, são os desenvolvedores que dão instruções aos mantenedores e usuários do sistema e usam os números da versão para transmitir suas instruções. Para mim, cada jogador deve decidir de acordo com seus critérios, e o número da versão deve atuar como meio de comunicação factual no nível mais grosseiro.

Dado que o NumPy não tem implicações de segurança, não vejo como e por que o projeto NumPy deve dar recomendações universais. Pessoas e instituições têm necessidades diferentes. É por isso que temos tanto o ArchLinux quanto o CentOS, com políticas de atualização muito diferentes.

@khinsen O oldnumeric ainda funciona perfeitamente e as pessoas podem instalá-lo com:

pip install oldnumeric

Talvez esta seja sua proposta de "numpy estável", em que a interface para numpy é restrita a Python / Cython e nada é alterado. Claro, escrever código com oldnumeric é muito misterioso, mas você não pode ter as duas coisas.

@xoviat Verdade, mas esse é um problema diferente. Meu ponto aqui não é a preservação do software, mas a comunicação entre os diferentes participantes do gerenciamento de software.

Pergunta: Como administrador de sistemas (mesmo apenas em sua máquina pessoal), você esperaria que um pacote eliminasse uma camada API completa da versão 1.8 para a versão 1.9?

Para aqueles que responderam "sim", a segunda pergunta: você pode nomear algum software diferente de numpy que já fez isso?

A propósito, posso garantir que muitas pessoas foram mordidas por isso, porque recebi muitos e-mails perguntando por que o MMTK parou de funcionar de um dia para o outro. Todas essas pessoas fizeram atualizações de rotina em suas instalações de software, sem esperar consequências graves.

Mas perder oldnumeric não foi o pior evento da história recente do NumPy. Essa honra vai para a alteração da semântica de cópia / visualização de algumas operações, como diagonal . O código que retorna resultados diferentes dependendo da versão do NumPy (alteração secundária do número da versão!) É um verdadeiro pesadelo.

A propósito, já que quase ninguém conhece a história: pip install oldnumeric funciona desde dois dias atrás, porque @xoviat preparou este pacote add-on e o colocou no PyPI. Muito obrigado!

você esperaria que um pacote eliminasse uma camada API completa da versão 1.8 para a versão 1.9?

A qual camada você está se referindo?

você pode citar qualquer software diferente de numpy que já fez isso?

SciPy descartou weave e maxentropy pacotes, pandas quebra os principais recursos regularmente. Tenho certeza de que existem muitos outros exemplos proeminentes. EDITAR: o próprio Python, por exemplo, consulte https://docs.python.org/3/whatsnew/3.6.html#removed

A propósito, posso garantir que muitas pessoas foram mordidas por isso, porque recebi muitos e-mails perguntando por que o MMTK parou de funcionar de um dia para o outro. Todas essas pessoas fizeram atualizações de rotina em suas instalações de software, sem esperar consequências graves.

Essa mudança demorou cerca de 10 anos para ser feita, e não há como um esquema de versão diferente ter feito a diferença aqui.

Eliminar recursos obsoletos é uma troca entre quebrar uma pequena fração do código (mais antigo) e manter a base de código fácil de manter. No geral, se estamos errando, provavelmente estamos fazendo isso por sermos conservadores. Como alguém que também teve que lidar com grandes bases de código corporativo de muitos anos que usam numpy, sinto sua dor, mas você está defendendo algo que absolutamente não é uma solução (e em geral não há solução completa; educar os usuários sobre coisas como fixar versões e verificar avisos de suspensão de uso é o melhor que podemos fazer).

A qual camada você está se referindo?

suporte numérico / numarray, presumo

@rgommers Desculpe, eu deveria ter dito "outro exemplo fora do ecossistema SciPy".

Além disso, não estou reclamando de descartar o suporte para oldnumeric . Estou reclamando sobre fazer isso sem uma alteração no número da versão principal.

Que diferença isso teria feito? Isso teria feito as pessoas hesitarem em atualizar sem ler as notas de lançamento. Todo mundo usando (mas não desenvolvendo) código Python teria tomado isso como um sinal de cuidado.

Não se esqueça de que o ecossistema SciPy tem um número enorme de usuários discretos que não estão acompanhando ativamente os desenvolvimentos. Python e NumPy são itens de infraestrutura da mesma natureza que ls e gcc para eles. E geralmente é menos do que isso: eles usam algum software que por acaso foi escrito em Python e simplesmente depende do NumPy, e quando ele quebra, eles se perdem completamente.

@rgommers Desculpe, eu deveria ter dito "outro exemplo fora do ecossistema SciPy".

Acabei de editar minha resposta com um link para as notas de versão do Python, que estão fora do ecossistema SciPy.

Que diferença isso teria feito? Isso teria feito as pessoas hesitarem em atualizar sem ler as notas de lançamento. Todo mundo usando (mas não desenvolvendo) código Python teria tomado isso como um sinal de cuidado.

Isso simplesmente não será o caso. Se em vez de 1.12, 1.13, 1.14, etc, tivermos 12.0, 13.0, 14.0, os usuários se acostumarão com isso e usarão a mesma estratégia de atualização de antes. A grande maioria não se tornará de repente muito mais conservadora.

Não se esqueça de que o ecossistema SciPy tem um número enorme de usuários discretos que não estão acompanhando ativamente os desenvolvimentos. Python e NumPy são itens de infraestrutura da mesma natureza que ls e gcc para eles. E geralmente é menos do que isso: eles usam algum software que por acaso foi escrito em Python e simplesmente depende do NumPy, e quando ele quebra, eles se perdem completamente.

Tudo verdade, e nem tudo corrigível magicamente por um número de versão. Se eles executaram pip install --upgrade numpy , eles precisam saber o que estão fazendo (e de qualquer forma, nem mesmo mostram o número da versão). Se for o sistema de empacotamento deles, eles estão vendo o problema do software que quebra por não ter um conjunto de testes decente (ou que não foi executado).

Outras desvantagens de mudar o esquema de versão agora:

• estaríamos fazendo uma mudança no controle de versão sem uma mudança na política de manutenção, será mais confuso do que útil
• agora estamos basicamente seguindo o exemplo do Python e fazendo o mesmo que o resto de todo o ecossistema. Isso é uma coisa boa
• talvez o mais importante: estaríamos perdendo a capacidade de sinalizar mudanças realmente importantes. o tipo para o qual iríamos para 2.x, como uma versão que quebraria a ABI.

Minha referência básica não é Python, mas uma instalação típica de software. Como eu disse, para muitos (talvez a maioria) usuários, NumPy é uma infraestrutura como gnu-coreutils ou gcc. Eles não interpretam os números de versão especificamente no contexto do ecossistema SciPy.

Fiz uma verificação rápida em um sistema Debian 9 com cerca de 300 pacotes instalados. 85% deles têm um número de versão começando com um inteiro seguido por um ponto. Os prefixos inteiros mais comuns são 1 (30%), 2 (26%), 0 (14%) e 3 (13%). Se o NumPy adotasse um esquema de numeração de versão em conformidade com as expectativas comuns (ou seja, versão semântica ou uma aproximação aproximada), ele definitivamente se destacaria e seria tratado com cautela.

Observe também que as únicas atualizações no software instalado pelo Debian que quebraram coisas para mim foram no ecossistema SciPy, com a única exceção de uma atualização do Emacs que trouxe mudanças no modo org que quebrou uma extensão do modo org caseiro. Os prefixos de número baixo de versão geral, portanto, parecem indicar que o software mais amplamente usado é muito mais estável do que NumPy e amigos.

A uniformidade em todo o ecossistema SciPy é de fato importante, mas eu preferiria que todo o ecossistema adotasse um esquema de controle de versão de acordo com as expectativas do mundo externo. Estou apenas começando com NumPy porque o vejo como a parte mais básica. É ainda mais infraestrutura do que qualquer outra coisa.

Por fim, considero uma mudança na semântica de uma função uma mudança muito mais importante do que uma mudança na ABI. O primeiro pode causar pesadelos de depuração para centenas de usuários e fazer com que os programas produzam resultados errados não detectados por anos. O último leva a mensagens de erro que indicam claramente a necessidade de consertar algo.

De acordo com esses padrões, o NumPy nem mesmo está seguindo o exemplo do Python, porque as únicas mudanças na semântica que conheço na linguagem Python aconteceram de 2 para 3.

Por fim, considero uma mudança na semântica de uma função uma mudança muito mais importante do que uma mudança na ABI. O primeiro pode causar pesadelos de depuração para centenas de usuários e fazer com que os programas produzam resultados errados não detectados por anos. O último leva a mensagens de erro que indicam claramente a necessidade de consertar algo.

Isso nós tentamos muito não fazer. A quebra clara quando algum recurso é removido pode acontecer, mas os resultados numéricos mudando silenciosamente, não. Isso é uma coisa que aprendemos com a mudança da visão diagonal - isso foi um erro em retrospectiva.

definitivamente se destacaria e seria tratada com cautela.

Eu ainda discordo. Mesmo no Debian, que definitivamente não é "uma instalação típica de software" para nossa base de usuários (seria algo como o Anaconda no Windows). Você também parece ignorar meu argumento acima de que um usuário nem consegue ver um número de versão normalmente (nem com pip install --upgrade ou com um gerenciador de pacotes).

Além disso, sua experiência de que tudo o mais nunca quebra é provável porque você está usando coisas como utilitários do sistema operacional e programas de GUI, não outras grandes cadeias de dependências. Por exemplo, todo o ecossistema JavaScript / NodeJS é provavelmente mais frágil do que o do Python.

Aliás, posso garantir que muitas pessoas foram mordidas por isso, porque recebi muitos e-mails perguntando por que MMTK parou de funcionar de um dia para o outro

Este é um bom exemplo das sutilezas aqui. Até onde eu sei, MMTK e seus outros projetos são os únicos ainda existentes que foram afetados pela remoção do código de compatibilidade numérico / numarray. Quantos usuários você estima que tem? 100? 1000? NumPy tem milhões, então talvez 0,1% dos nossos usuários foram afetados por esta remoção? Definitivamente, não é zero, e o fato de ser pequeno não significa que não tenha importância - gostaria que pudéssemos oferecer suporte a 100% dos usuários para sempre de todas as maneiras. E eu entendo que é particularmente doloroso para você receber 100% das reclamações de seus usuários.

Mas se aumentarmos nosso número de versão principal para isso, significa que para 99,9% dos nossos usuários, acabamos de gritar lobo. É um falso positivo. OTOH para aquele 0,1% dos usuários, foi muito importante. No entanto, não é incomum que quebremos mais de 0,1% dos usuários em micro- versões, apesar de nossos melhores esforços. Então, o que fazemos?

Simplesmente não é possível comunicar essas nuances por meio do instrumento contundente de um número de versão. Todos querem uma maneira rápida de saber se uma atualização quebrará seu código, por bons motivos. Semver é popular porque promete fazer isso. É popular pelo mesmo motivo que é popular pensar que as dietas da moda podem curar o câncer. Gostaria que o Semver também cumprisse suas promessas Mas isso não acontece, e se queremos ser bons engenheiros, precisamos lidar com as complexidades dessa realidade.

Não vejo como e por que o projeto NumPy deve dar recomendações universais. Pessoas e instituições têm necessidades diferentes.

Damos recomendações universais porque temos apenas um número de versão, portanto, por definição, tudo o que fizermos com ele é uma recomendação universal. Não temos nenhum controle sobre isso.

Essa honra vai para a alteração da semântica de cópia / visualização de algumas operações, como diagonal .

IIRC: literalmente, não recebemos uma única reclamação sobre isso de alguém dizendo que violou seu código. (Talvez uma pessoa?) Não estou dizendo que isso significa que ninguém foi afetado, obviamente, as pessoas que reclamam de uma mudança são, em geral, apenas uma pequena fração das pessoas afetadas, mas se você usar as reclamações como uma representação aproximada da realidade impacto mundial, então não acho que esteja entre os 50 primeiros.

E, por falar nisso, tenho quase certeza de que se você pesquisar na história profunda, poderá encontrar mudanças muito mais notórias do que isso :-).

Observe também que as únicas atualizações no software instalado pelo Debian que quebraram coisas para mim foram no ecossistema SciPy, com a única exceção de uma atualização do Emacs que trouxe mudanças no modo org que quebrou uma extensão do modo org caseiro.

Respeitosamente, acho que isso diz mais sobre como você usa NumPy versus Debian do que sobre NumPy versus Debian. Eu amo o Debian, já o uso há quase 20 anos e não consigo contar quantas vezes ele está quebrado. Só na semana passada, algum problema bizarro com o novo gnome quebrou meus scripts de login e alguma outra atualização quebrou meu trackpoint . (Ambos foram corrigidos agora, mas ainda assim.) Também observarei que o emacs do Debian foi configurado para baixar e executar código em canais não criptografados / inseguros por anos, devido a problemas de compatibilidade com versões anteriores sobre a habilitação de verificações de segurança. Não acho que exista algo como um lançamento do gcc que não prejudique algumas pessoas, apenas porque as pessoas fazem coisas como usar -Werror e, em seguida, pequenas alterações no comportamento de aviso (que pode contar com sutis interações entre passos de otimização, etc.) tornam-se alterações significativas.

Os prefixos de número baixo de versão geral, portanto, parecem indicar que o software mais amplamente usado é muito mais estável do que NumPy e amigos.

Os prefixos de número de versão baixa geral são porque o software mais amplamente usado não usa semver.

Por fim, considero uma mudança na semântica de uma função uma mudança muito mais importante do que uma mudança na ABI. O primeiro pode causar pesadelos de depuração para centenas de usuários e fazer com que os programas produzam resultados errados não detectados por anos. O último leva a mensagens de erro que indicam claramente a necessidade de consertar algo.

Sim, é por isso que somos extremamente cautelosos com essas mudanças.

Há alguma desconexão de perspectivas aqui: você parece pensar que mudamos as coisas à toa o tempo todo, não ligamos para a compatibilidade com versões anteriores, etc. Posso respeitar isso; Eu entendo que reflete sua experiência. Mas nossa experiência é que colocamos extremo cuidado nessas mudanças, e eu diria que, quando falo com os usuários, são ~ 5% que têm sua perspectiva e ~ 95% que acham que o entorpecido está fazendo um bom trabalho na estabilidade, ou que está fazendo um trabalho muito bom e deve estar mais disposto a quebrar coisas. Talvez você possa se consolar em saber que, mesmo que o desapontemos, também desapontamos aquele último grupo :-).

com a única exceção de uma atualização Emacs

Bem, para sair do tópico, isso serve como um exemplo do outro lado da estabilidade. O Emacs permaneceu estático por anos devido à resistência de Stallman às mudanças, e isso resultou no fork do xEmacs. Meu próprio caminho foi Emacs -> xEmacs, para diabos, -> Vim;) Fossilização prematura também é o motivo pelo qual parei de usar o Debian naquela época. Para algumas coisas, a mudança simplesmente não é necessária ou mesmo desejada, e espero que existam pessoas executando versões antigas do BSD em hardware antigo escondido em um armário. Mas não creio que existam muitos desses lugares.

A propósito do problema atual, não acho que uma mudança no esquema de controle de versão faria qualquer diferença. Um caminho mais produtivo pode ser resolver o problema da modernização. @khinsen Você vê como aceitar a atualização de seus principais projetos? Nesse caso, acho que devemos explorar maneiras de ajudá-lo a fazer isso.

Estou tentando atualizar os projetos em
https://github.com/ScientificPython. Requer a atualização do código Python que
usava a API C antiga (e quero dizer antiga; algumas funções como Py_PROTO eram
de 2000). Os RP são bem-vindos, mas não tenho certeza se alguém
quer gastar seu tempo nisso.

A maior questão que acho que ele levantou é que existem "muitos
projetos "(não sei onde exatamente eles estão porque todos os projetos
que vi suporte a Python 3) que também precisa ser atualizado; como é
determinou quais projetos têm tempo de desenvolvedor NumPy alocado? E eu também
não acho que sua afirmação central era inválida: SciPy se beneficia muito com o
fato de que ele poderia simplesmente copiar e colar projetos fortran antigos (como
fftpack) com pouca ou nenhuma modificação. Se estes tivessem sido escritos em digamos
"fortran 2" e novos compiladores compilaram apenas "fortan 3", haveria
problemas significativos.

Dito isso, esses problemas não são realmente culpa do NumPy. Apesar do que ele tem
disse, com o NumPy 1.13 instalado, oldnumeric ainda passou em todos os testes,
indicando que o NumPy não é o culpado aqui. Como a API oldnumeric é
literalmente há mais de uma década (talvez quase duas décadas!), e ainda
funciona no NumPy mais recente, acho que a API NumPy é provavelmente estável
o suficiente.

@charris Concordo plenamente com você que "nunca mude nada" não é uma atitude produtiva na computação.

Meu ponto é que o ecossistema SciPy se tornou tão imensamente popular que nenhuma abordagem única para gerenciar a mudança pode atender a todos. Depende da rapidez com que os métodos e suas implementações evoluem em um determinado campo, das competências técnicas dos profissionais, de outro software de que dependem, dos recursos que podem investir em código, etc.

A atual equipe principal do NumPy se preocupa mais com o progresso (em uma direção que importa para alguns campos, mas é amplamente irrelevante para outros) do que com a estabilidade. Tudo bem - no mundo do código aberto, as pessoas que fazem o trabalho decidem no que querem trabalhar. No entanto, minha impressão é que eles não percebem que muitas pessoas cujo trabalho depende do NumPy têm necessidades diferentes, se sentem abandonadas pela equipe de desenvolvimento e estão começando a se afastar do SciPy para uma tecnologia mais tradicional e estável, como C e Fortran ( e, em um caso eu sei, até mesmo para Matlab).

Não tenho ideia de qual porcentagem de usuários do NumPy está suficientemente infeliz com o estado atual das coisas, e não acho que ninguém mais tenha. Depois que um pacote de software se torna infraestrutura, não é possível estimar facilmente quem depende dele. Muitos que o fazem nem mesmo estão cientes disso, e muitos códigos que dependem do NumPy (direta ou indiretamente) não são públicos e / ou não são facilmente descobertos.

Se quisermos manter todos felizes na comunidade SciPy, precisamos encontrar uma maneira de lidar com as diversas necessidades. O primeiro passo, em minha opinião, é transferir o controle sobre a taxa de mudança em uma instalação específica dos desenvolvedores para alguém que está mais próximo do usuário final. Podem ser os próprios usuários finais, ou administradores de sistemas, ou empacotadores, ou qualquer outra pessoa - novamente, não acho que haja uma resposta universal para essa pergunta. O que isso exige dos desenvolvedores são informações no nível certo, e é por isso que comecei este tópico. É claro que os números de versão não podem salvar o mundo, mas os vejo como um primeiro passo para estabelecer uma responsabilidade distribuída pelo gerenciamento de mudanças.

Finalmente, alguns de vocês parecem acreditar que estou travando uma batalha pessoal sobre meu próprio código. Pode surpreendê-lo que minha atitude pessoal não seja a que estou defendendo aqui. Meu próprio sweetspot para taxa de mudança está em algum lugar entre o que é comum em meu campo e o que parece ser predominante na equipe do NumPy. A maior parte do meu trabalho hoje usa Python 3 e NumPy> 1.10. MMTK tem 20 anos e hoje faço muitas coisas de maneira diferente. Freqüentemente, pego pedaços de código do MMTK que preciso para um projeto específico e os adapto ao "SciPy moderno", mas isso é algo que posso fazer com confiança apenas porque escrevi o código original.

Tenho mantido um MMTK estável como um serviço à comunidade, não para meu uso, o que explica porque tenho feito a manutenção de forma minimalista, evitando mudanças em grande escala na base de código. É muito difícil encontrar financiamento para software e desenvolvedores de domínio competente, então MMTK sempre permaneceu um projeto de um mantenedor mais contribuidores ocasionais. Eu nem tenho certeza de que portar todo o MMTK para o "SciPy moderno" faria bem a alguém, porque muito do código que depende do MMTK é completamente sem manutenção. Mas então, isso é verdade para a maior parte do código Python que vejo ao meu redor, até mesmo códigos completamente não relacionados ao MMTK. É a realidade de um domínio de pesquisa onde experimentos, em vez de computação e codificação, estão no foco das atenções.

@xoviat O número de testes em oldnumeric é ridiculamente pequeno. Eu não concluiria muito do fato de que eles passam com o NumPy 1.13.

Os módulos de extensão C que você está vendo têm literalmente 20 anos e foram escritos para Python 1.4. Naquela época, estava entre os exemplos mais sofisticados de combos Python-C e de fato moldou o desenvolvimento inicial de Numeric (pré-NumPy) e até mesmo do próprio CPython: CObjects (pré-cápsulas) foram introduzidos com base nas necessidades de ScientificPython e MMTK .

Sou o primeiro a dizer que as APIs e ferramentas de suporte de hoje são muito melhores e espero que ainda melhorem no futuro. Mas algumas pessoas simplesmente querem usar software para fazer pesquisas, não importa o quão antiquado seja, e eu acho que eles têm o direito de existir também.

@rgommers Não estou ignorando seu argumento de que um usuário nem consegue ver o número da versão. Simplesmente não é verdade para os ambientes que vejo as pessoas usarem ao meu redor. As pessoas que decidem sobre as atualizações (que nem sempre são os usuários finais) o veem. Eles não fazem apenas "pip install --upgrade" uma vez por semana. Eles até considerariam isso uma atitude descuidada.

Se as pessoas ao redor usam principalmente o Anaconda no Windows, isso só confirma que trabalhamos em ambientes muito diferentes. Na era da diversidade, espero que possamos concordar que cada comunidade possa adotar as ferramentas e convenções que funcionam bem para ela.

E sim, NodeJS é pior, concordo. Felizmente, posso ignorar isso facilmente.

Acabei de receber um e-mail de um colega que segue este tópico, mas não se atreve a interferir. Com uma excelente analogia:

"Eu adoro quando tenho a chance de comprar um novo microscópio e fazer ciência melhor com ele. Mas eu odiaria ver alguém substituindo meu microscópio durante a noite sem me consultar."

É tudo uma questão de ter controle sobre as próprias ferramentas.

Prometo que nunca vou invadir o laboratório do seu colega no meio da noite e atualizar seu numpy. Eu nem tenho uma balaclava .

As pessoas que decidem sobre as atualizações (que nem sempre são os usuários finais) o veem. Eles não fazem apenas "pip install --upgrade" uma vez por semana. Eles até considerariam isso uma atitude descuidada.

Se eles são administradores de sistemas e entendem os prós e os contras de vários métodos de instalação, então eles realmente deveriam entender (ou ser ensinados) como funciona o controle de versão no mundo Python (e muitos outros projetos de software que também não usam o estrito semver).

A atual equipe principal do NumPy se preocupa mais com o progresso (em uma direção que importa para alguns campos, mas é amplamente irrelevante para outros) do que com a estabilidade.

Sinto muito, mas isso apenas mostra que você não tem acompanhado o desenvolvimento do NumPy nos últimos anos, ou tem um conjunto de óculos muito específico. NumPy é realmente um projeto muito difícil de contribuir, porque há muita preocupação com a compatibilidade com versões anteriores. Essa é uma das principais razões pelas quais temos dificuldade em atrair novos mantenedores.

e, em um caso eu sei, até mesmo para Matlab

O Matlab era famoso por quebrar a compatibilidade. A primeira coisa que os projetos cooperativos usando Matlab fizeram foi especificar a versão que todos deveriam usar, o mesmo com o Microsoft Word se ele estava sendo usado para documentação. Eu conheço pessoas que mudaram para o NumPy precisamente para melhorar a compatibilidade. O Matlab tem suas virtudes, mas a compatibilidade não é / não era uma delas. Talvez as coisas tenham mudado?

No entanto, acho que há algumas coisas que podemos fazer daqui para frente que podem ajudar na compatibilidade. O primeiro está relacionado à discussão atual sobre NEPs. Agora que o NumPy está mais maduro, pode ser uma boa ideia fazer mais uso dos NEPs quando mudanças que afetam a compatibilidade estão sendo propostas, especialmente se os NEPs são mais públicos e pesquisáveis. Em segundo lugar, poderíamos tentar criar rodas para versões mais antigas do NumPy no PyPI se isso não for muito trabalhoso. O uso de ambientes virtuais parece ser a melhor ideia atual para obter reprodutibilidade, e ter uma seleção mais ampla de rodas para download pode ajudar nisso.

Em segundo lugar, poderíamos tentar criar rodas para versões mais antigas do NumPy no PyPI se isso não for muito trabalhoso.

Graças aos esforços de @matthew-brett, parece que o status atual é que o Windows volta para 1.10 , o MacOS volta para 1.5 (exceto 1.7 está faltando ) e o Linux volta para 1.6 .

A situação do MacOS / Linux parece bastante razoável. Acho que poderíamos preencher mais versões do Windows? OTOH pip install no Windows nunca funcionou sem esforços heróicos, então não tenho certeza se há um grande público para isso. Já temos 2 anos, e isso vai crescer com o tempo.

Além disso, da última vez que carregamos rodas antigas, alguém ficou com raiva de nós porque seu fluxo de trabalho presumiu que não havia rodas e quebrou a compatibilidade com versões anteriores para eles :-)

Adoraria ouvir essa história.

Não que eu realmente conheça bem essas coisas, mas acho que podemos tentar melhorar as coisas (não tenho muita certeza do que isso significa!), O fato é que precisamos avançar lentamente e, exceto por possivelmente alguns erros, todos os lançamentos foram destinada a quebrar o código de muito poucas pessoas. Acho que nosso lançamento menor significa "quase todas as pessoas deveriam atualizar e ser capazes de atualizar sem perceber nada", e eu sinceramente acredito que isso é verdade. (Obviamente, há coisas que afetaram muitas pessoas, como depreciações de inteiros, mas elas não criam resultados errados e demoraram a ser criadas)

Posso ver que pode ter havido algumas mudanças grandes o suficiente para garantir o incremento da versão principal, embora francamente não tenha certeza de qual seria. E sim, talvez haja alguma perda histórica de impulso quando se trata de grandes lançamentos.

Em qualquer caso, também não posso dizer que sou fã de dizer que (quase) todo lançamento é um lançamento importante. Eu entendo que podemos ter irritado as pessoas com algumas mudanças, mas eu participei de algumas mudanças bastante extensas e todas as vezes depois de explicar as razões eu só ouvi que era a coisa certa a fazer, e também esperamos por anos até que essas mudanças entrassem em vigor.

Quanto ao gcc, etc. Por exemplo, não sei muito sobre compilar / C ++, fiquei incomodado com o gcc 4.8 ou então começando a me forçar a descobrir como alterar os sinalizadores corretamente por causa de alguns recursos do C ++ 11 ou assim sendo esperado, o que causa reações muito semelhantes aos e-mails que você parece estar recebendo sobre entorpecido, então não tenho certeza se é muito diferente :).

De qualquer forma, não quero discutir muito aqui, agradeço o feedback sobre se podemos ser rápidos demais ou não cuidadosos o suficiente, mas tenho que admitir que também não vejo que alterar a versão principal ajudará muito com este. Pessoalmente, acho que 1.13 e 1.6 são pelo menos uma versão principal separada em algum sentido, mas não há uma única versão que eu possa apontar e dizer: essa foi uma grande quebra de compatibilidade para muitos usuários.
Lembro-me de ter lido comentários no código: "Vamos fazer isso no Numpy 2 talvez", exatamente por medo de qualquer quebra, com essa abordagem temo que o Numpy teria parado muito e, francamente, estou um pouco orgulhoso de fazer parte do que para mim pelo menos parecia uma fase mais ativa de novo que era necessária e que teria sido difícil se fôssemos ainda mais conservadores. (Provavelmente sou tendencioso, pois não tenho muita ideia do que aconteceu antes de eu vir :)).

Desculpe, talvez isso não faça sentido (acabamos de fazer uma festa de Natal). A proposta do Semver faz sentido, mas devo admitir que não parece uma solução real. Posso concordar em tentar incrementar a versão principal de forma mais agressiva, mas também discordo em chamar basicamente toda versão de versão principal. Também posso concordar em tentar ser mais conservador em alguns casos, mas francamente não tenho certeza do que são (basta contar o número de PRs pendurados, porque ninguém tem certeza se isso pode quebrar a compatibilidade em algum lugar;), tenho certeza que é uma boa porção)?

E mesmo que eu tenha lido reclamações, se você trouxer um pouco de bugiganga e insistência, não é como se não desfazermos todas as alterações se for razoavelmente possível ou pelo menos atrasá-las por um ano ou mais. Eu diria que é uma parte da razão pela qual escolhemos um modelo de governança conservador….

Então, depois de balbuciar por tanto tempo:

• "Quase nenhum código está quebrado" parece OK para uma versão secundária?
• Temos que avançar devagar?
• As coisas irão quebrar eventualmente, e talvez possamos incrementar a versão principal algumas vezes. Possivelmente, tente fazer algum tipo de FutureWarning alterando mais nas versões principais. (Francamente, não acredito que vá ajudar, mas estou disposto a tentar)

Mais importante: eu sei a frustração, mas existe uma solução real para nós? Você acha que se incrementarmos a versão principal agressivamente, você receberá menos e-mails?

@xoviat, você está perguntando sobre a história de

Minha definição favorita de semver (que não consigo mais encontrar um link para a postagem original):

• principal: quebramos o código do usuário propositalmente
• menor: quebramos o código do usuário por acidente
• patch: quebramos as soluções do usuário para os bugs do último lançamento menor

o que é um pouco atrevido, mas acho que acontece uma coisa de importação, _qualquer_ mudança no comportamento vai quebrar algum usuário em algum lugar. Isso é particularmente verdadeiro com projetos que possuem grandes superfícies de API.

O primeiro passo, em minha opinião, é transferir o controle sobre a taxa de mudança em uma instalação específica dos desenvolvedores para alguém que está mais próximo do usuário final.

Acho que algo que está faltando nesta conversa é que versões antigas de bibliotecas estão sempre disponíveis (em pypi da fonte), então se você tiver um código que requer uma versão antiga de python / numpy / matplotlib, use as versões mais antigas. Os ambientes de espaço do usuário tornam isso não muito difícil de gerenciar.

Se você quiser usar novas versões das bibliotecas, terá que pagar o custo de acompanhar as mudanças. Para fazer a analogia do microscópio, você precisa fazer a manutenção de rotina em seu microscópio ou ele se degrada com o tempo; o software não é diferente.

@njsmith Isso é muito engraçado. IMO # 7570 não é um problema válido, visto que
NumPy está em conformidade com a especificação de roda manylinux. Geralmente, rodas
deve ser carregado para versões mais antigas, assumindo que o tempo é livre. Dado
que o tempo não é livre, podemos simplesmente observar que as pessoas podem construir rodas
para uma versão específica do NumPy se eles quiserem; enviar um PR para o
repositório numpy-wheels. Ou não.

@xoviat Quero dizer, se o sistema deles quebrou, quebrou; ser capaz de apontar para uma especificação não muda isso. Em geral, nessas discussões, acho que devemos nos preocupar mais com os efeitos reais sobre os usuários finais do que com a pureza teórica. Mas OTOH, neste caso, acho que foi a decisão certa manter as rodas funcionando, visto que eles já haviam contornado o problema, as rodas já estavam carregadas e, pelo que podemos dizer, havia muito mais pessoas se beneficiando do que Ter problemas. Mas é um lembrete interessante de como a "incompatibilidade com versões anteriores" pode ser sutil e de como é difícil fazer regras genéricas.

@njsmith Seu papel na analogia do microscópio é o de um vendedor de microscópio que se aproxima do diretor do laboratório do meu colega com uma oferta para substituir todos os microscópios do laboratório por seu último modelo, escondendo a frase "incompatível com amostras com mais de 1 mm de espessura" nas letras miúdas do contrato. Isso torna muito difícil para o diretor do laboratório entender que há um ponto técnico que precisa ser discutido com as pessoas que entendem esses detalhes.

@rgommers Eu entendo que manter o NumPy é uma tarefa árdua e, na verdade, eu

Por outro lado, certamente admito ter um conjunto de óculos muito particular, mas isso é verdade para todos os outros nesta discussão. Meus óculos são os da "computação científica tradicional", que é o meu ambiente de trabalho. A linha de base (expectativa padrão) é que as atualizações nunca interrompam nada intencionalmente. Essa é a política das linguagens padronizadas (C, Fortran), mas também das bibliotecas de infraestrutura (BLAS, LAPACK, MPI, ...). No entanto, a inovação acontece (por exemplo, ATLAS). Se você acha isso conservador, deixe-me descrever o que conservador significa no meu mundo: nunca instale uma versão de nada que não tenha pelo menos dois anos, para ter certeza de que a maioria dos bugs são conhecidos. Essa é uma política comum para supercomputadores cujo tempo é muito caro e cujos resultados dificilmente podem ser verificados por esse motivo.

Observe que não estou dizendo que o NumPy deve adotar as expectativas padrão do meu mundo. Estou apenas dizendo que deve sinalizar claramente que é diferente.

@seberg "Quase nenhum código está quebrado" parece bom em teoria para uma versão secundária. Mas, uma vez que um pedaço de software adquire o status de infraestrutura (e na minha opinião, o NumPy está nesse nível), é impossível estimar quantos desenvolvedores e usuários podem ser afetados. O critério então se torna invariavelmente "quase ninguém em quem eu consigo pensar é afetado", e isso não é bom.

@tacaswell Acho que a diferença entre "propositalmente" e "por acidente" é muito importante na prática. Afeta a atitude de todos em relação a uma mudança. Basta olhar para outros aspectos da vida. Se a distinção não importasse, poderíamos retirar a palavra "cuidado" do idioma inglês.

Bem, francamente, acho que a ideia de "grande redesenvolvimento" está praticamente abandonada agora, já que exigiria muito mais poder de desenvolvimento e poderia criar um tipo totalmente diferente de confusão (consulte py2 e py3 nos primeiros anos).

Concordo, numpy é infraestrutura, mas eu não sou um fã de apenas agir como se quebrar o código de mais pessoas fosse OK / intenção, alterando versões principais mais rápido é uma solução. É mais como desistir da tarefa de tentar o nosso melhor para fazer versões do tipo "quase nenhum código é corrompido" (talvez com a exceção "a menos que você não tenha assistido a avisos para algumas versões"), e então realmente ajudar na decisão de atualização.

Portanto, às vezes devemos reconhecer que pode não ser verdade, mas de outra forma eu preferiria obter soluções para garantir que não quebremos mais. Claro que você ofereceu uma solução (sendo muito conservador e começando numpy 2 com uma grande reforma), mas uma vez que admitimos que essa solução simplesmente não é viável sem um grande financiamento ou algo assim, o que mais podemos fazer?

Ou deixe-me ser claro: se você conhece alguém capaz de seguir um dev entorpecido que consegue ficar de olho em ser mais conservador quando necessário, você sabe que eu pelo menos aprecio isso. Mas eu pessoalmente não aprecio desistir de nosso progresso de, pelo menos, lentamente nos livrarmos de alguns dos cantos mais escuros para permitir um desenvolvimento futuro. Na melhor das hipóteses, acabaríamos com um NumPy morto e um substituto em alguns anos, na pior, acabaríamos sendo ultrapassados ​​e frustrados por não sermos capazes de avançar e talvez "substitutos" brotando, que por natureza se não ser tão maduro, só piora as coisas.

Tenho que concordar com @seberg sobre a criação de um namespace diferente. o
toda suposição por trás dessa ideia é que o projeto NumPy tem
talento e recursos para manter uma biblioteca que funcione para todos.
No entanto, esse não é o caso. Os desenvolvedores não são perfeitos, então geralmente
errar na primeira vez. As pessoas que escrevem o código numérico original
não poderia prever todos os cenários em que seria usado, e eles
não poderia prever o aumento de implementações alternativas, como PyPy.

Eu acho que a estabilidade da API é muito importante. Eu também acho que o NumPy tem
geralmente acertou. O fato é que o NumPy já está
difícil de raciocinar (e deveria ser, dado que até a última gota de
o desempenho é importante), mas criar um namespace diferente o tornaria
extremamente difícil manter todas as implicações da mudança de código em
sua cabeça. Eu acho que é altamente provável que se NumPy fizesse isso, haveria
ser significativamente mais bugs porque os desenvolvedores não entendem o
ramificações de mudança de código em uma interface na outra.

Em resumo, entendo perfeitamente as frustrações das pessoas. Mas como @njsmith
disse, não há soluções para o problema que irão satisfazer todos os usuários.
Existem apenas soluções que irão satisfazer a maioria dos usuários na maioria das vezes. E
a realidade é que se o NumPy alcançasse a minoria de usuários (não significava
de forma depreciativa) que exigia estabilidade da API sobre tudo o mais, o
O financiamento do NUMFOCUS pode acabar porque não ficaria claro qual é o dinheiro
foi usado, e então onde estaríamos? Provavelmente em uma situação onde
MMTK não pode mais depender do NumPy, assim como a situação em que poderia
não dependem mais do Numeric.

Eu colocaria o código atual no modo de manutenção mínima e iniciaria um grande redesenho em um namespace diferente, deixando o antigo e o novo coexistirem indefinidamente com a interoperabilidade por meio da interface do buffer. E sim, eu sei que este não é um esforço trivial por vários motivos, mas acho que é a única maneira de sair da pilha de dívidas técnicas acumuladas. O principal objetivo do redesenho seria a sustentabilidade.

Na verdade, concordo com você, mas não vejo como isso seja viável sem uma grande injeção de financiamento / visão. NumPy constitui um enorme trabalho. Talvez @teoliphant e @skrah consigam dar certo , mas será uma batalha difícil.

Dado o NumPy que temos hoje, acho que estamos indo tão bem quanto podemos razoavelmente.

Para aqueles que responderam "sim", a segunda pergunta: você pode nomear algum software diferente de numpy que já fez isso?

Django é outro software notável que não usa controle de versão semântico. Eles usam mudanças importantes para indicar quebras substanciais, mas descontinuam coisas em mudanças .x após um longo período de avisos. Mais ou menos como NumPy.

Na verdade eu concordo com você,

@shoyer sem interesse, por quê? Como isso não se transformaria em uma transição semelhante ao py3k muito dolorosa para a nova base de código em algum ponto?

Essa é a política das linguagens padronizadas (C, Fortran), mas também das bibliotecas de infraestrutura (BLAS, LAPACK, MPI, ...). No entanto, a inovação acontece (por exemplo, ATLAS).

A inovação no ritmo de LAPACK / ATLAS / OpenBLAS é uma receita para o NumPy se tornar irrelevante muito mais rápido do que seria de outra forma.

Veja, deve estar claro para você, a partir de todas as respostas, que essa mudança de versão não vai acontecer, e esse é o consenso entre os cerca de 7 devs principais ativos mais alguns desenvolvedores dos principais projetos downstream. Se você precisa de estabilidade absoluta, provavelmente será melhor apenas fixar uma versão fixa em seus sistemas por alguns anos e instruir seus administradores de sistema sobre isso.

Como isso não se transformaria em uma transição semelhante ao py3k muito dolorosa para a nova base de código em algum ponto?

A grande diferença é que enquanto o Python 3 é uma opção tudo / nada (para programas Python), é fácil ou pelo menos factível misturar / combinar diferentes bibliotecas ndarray. A interface do buffer significa que você pode transferir dados para frente e para trás sem cópias. Se você coagir entradas para suas funções com np.asarray() você pode nem perceber se alguma biblioteca com a qual está trabalhando muda para retornar arrays de um tipo diferente.

Isso soa como repetir partes do numérico / numarray / numpy
experiência, o que também não foi muito agradável (a interface do buffer
ajuda, mas acho que essa transição ainda envolverá código manual
mudanças, nem todas triviais). Também não será possível
para bibliotecas como Scipy para "atualizar" para a "nova matriz" sem
quebrando a compatibilidade com versões anteriores, então o problema simplesmente surge
o ecossistema, forçando outras bibliotecas a tomar uma decisão semelhante para
abandonar namespaces antigos.

Se todos coagissem suas entradas com np.asarray , então np.matrix não seria um problema :-).

Se diferentes bibliotecas de array concordarem com os tipos de pato e nós restringirmos os dtypes representáveis ​​pelo protocolo do buffer, então ele pode funcionar. Mas se todo o objetivo de uma reescrita seria fazer alterações de interface incompatíveis nos objetos do array e implementar novos dtypes, ... Eu realmente não vejo como fazer isso funcionar. Exemplo concreto: uma coisa óbvia a corrigir neste tipo de reescrita seria o comportamento de ndarray.dot em entradas de alta dimensão. Mas se houver uma biblioteca por aí que faça def f(a, b): a.dot(b) , então criar tal biblioteca irá potencialmente quebrá-la. Não importa realmente se essa biblioteca é chamada de numpy ou não.

E isso antes mesmo de entrar na impossibilidade geral de reescrever tudo em um big bang, mantendo a atenção do desenvolvedor enquanto fazemos isso, e não apenas acertando, mas tornando muito melhor que pode convencer as pessoas a migrar - tudo sem qualquer feedback incremental dos usuários. Acho que dynd é um exemplo instrutivo aqui.

@rgommers Por favor, leia novamente o que escrevi: Eu não proponho, repito,

@njsmith Um aspecto importante de um redesenho, a meu ver, seria abandonar o OO. Não é uma boa abordagem para estruturar o código para uma única estrutura de dados com toneladas de funções que funcionam nela. Escreva np.dot(a, b) e o problema que você descreve evaporará instantaneamente. Você pode ter qualquer número de implementações de namespace.dot desejar. Cada biblioteca pode usar a que desejar e ainda assim podem interoperar. É o OO que cria um único namespace para métodos, e isso é um problema.

Sim, essa é uma grande ruptura com os hábitos do Python. E sim, será complicado implementar operadores além disso. Mas acho que pode ser feito, e acho que vale a pena o esforço.

Só para mostrar que posso ser a favor de quebrar coisas ;-)

@rgommers Por favor, leia novamente o que escrevi: Eu não proponho, repito, não, que o NumPy deva adotar o ritmo do LAPACK.

Eu entendi aquilo. Os dois parágrafos da minha resposta não estavam diretamente relacionados, desculpe se isso foi confuso.

Proponho que isso sinalize claramente para as pessoas que têm essa expectativa (ou seja, 80% das pessoas em meu ambiente) de que não.

Era o que eu estava dizendo, o consenso parece ser que sua proposta será rejeitada. Você terá que simplesmente solicitar uma versão fixada para esses 80% e explicar por que é isso que você deseja.

@khinsen OK, então finja que meu exemplo foram as mudanças incompatíveis na indexação que certamente faríamos se fosse possível. (A indexação extravagante tem alguns casos extraordinariamente confusos.)

@njsmith Mesmo problema, de certa forma. A indexação é uma chamada de método em Python, então é OO novamente.

Observação lateral: A indexação extravagante é o maior erro de design no NumPy, na minha opinião, porque ela nem mesmo tem (e nunca teve) uma especificação inequívoca. Ele faz np.take para argumentos inteiros e np.repeat para argumentos booleanos. Como os booleanos são um subtipo de inteiros em Python, isso cria uma ambigüidade para argumentos contendo apenas 0s e 1s.

Na verdade, há uma relação com o tópico deste tópico, porque esse é exatamente o tipo de erro de design que acontece quando o desenvolvimento avança muito rápido.

Discuto a indexação sofisticada em meus cursos de SciPy exclusivamente para dizer às pessoas que não a utilizem. Existem np.take e np.repeat que funcionam perfeitamente bem e não causam problemas. E se você usá-los como funções em vez de métodos, não há problema OO também. Para aqueles que não gostam de np.repeat porque o nome não sugere a intenção quando usado com booleanos, apenas introduza um alias: select = np.repeat . Novamente algo tornado desnecessariamente difícil por OO.

Observe também que a indexação simples não está sujeita a esse tipo de problema. Ele faz o que quase todos esperariam que fizesse em todas as circunstâncias possíveis, portanto, pode ser implementado em um método.

A questão espinhosa do meu ponto de vista é aritmética. Você quer escrever a+b para adição de array, em vez de np.add(a, b) , mas não existe um acordo universal sobre o que exatamente a+b deve fazer, em particular em termos do tipo de resultado . Esse foi um dos principais problemas da divisão Numeric / numarray, que levou à introdução de novos tipos escalares no NumPy, e eles também causam uma boa quantidade de surpresas desagradáveis. Acredito que esse problema pode ser resolvido, mas não em comentários colaterais em uma discussão de problema do GitHub.

@rgommers Se "solicitar uma versão fixada para 80%" fosse possível, eu já teria feito isso há muito tempo. "Esses 80%" não é uma comunidade organizada com a qual você pode conversar. É um grande número de pessoas que compartilham uma cultura de fundo, mas não interagem umas com as outras. Sua sugestão é um pouco como "solicitar aos usuários do Windows que mudem para o Linux" (ou vice-versa).

Este é o ponto que estou tentando mostrar ao insistir em que o NumPy seja um software de infraestrutura. Para muitas pessoas, é apenas um entre centenas de blocos de lego que compõem a instalação do software. Eles não se preocupam especificamente com isso, apenas precisa estar lá e "funcionar".

Não quero sabotar isso muito mais, mas não tenho ideia do que você está se referindo com matrizes np.repeat e bool

@ eric-wieser repita 0 vezes e você o remove do array, 1 vezes e ele permanece. Eu discordo em ensinar isso em vez de indexar, mas enfim (a pior estranheza já passou, então sim, em numpy um bool não é um int na maioria dos casos, aceitando isso, você está bem agora eu acho, então isso é até uma incompatibilidade com listas se você deseja vê-lo assim, mas ...).

Um ponto lateral, já que isso não vai mais a lugar nenhum de qualquer maneira :). Na verdade, espero que consertar lentamente as coisas no numpy torne mais fácil, em algum ponto no futuro, tornar o numpy mais substituível.

Sua sugestão é um pouco como "solicitar aos usuários do Windows que mudem para o Linux" (ou vice-versa).

Hmm, pedir às pessoas que são tecnicamente competentes (espero ...) para aprender como os números de versão no mundo real realmente funcionam não é nada como uma mudança de Windows para Linux.

Este é o ponto que estou tentando mostrar ao insistir em que o NumPy seja um software de infraestrutura.

E presumivelmente, se fizéssemos essa mudança, você passaria para o SciPy porque é o próximo bit de infraestrutura? Quando deixa de ser infraestrutura? E por que o NumPy e os outros bits de infraestrutura desejam ter um esquema de versão completamente diferente do próprio Python e do resto de todo o ecossistema científico do Python?

Que 80% "não é uma comunidade organizada com a qual você pode conversar.

Os administradores do (s) supercomputador (es) que você usa realmente deveriam conversar uns com os outros, certo? Não pode haver um monte de gente rodando em torno de todos os softwares de atualização nesses dois sistemas e nunca falando. Eu não quis dizer que você deve educar 80% de todos os administradores de sistemas em todo o mundo, apenas aqueles que você precisa.

@seberg Declarar que listas e arrays são diferentes tipos de dados que compartilham apenas a indexação como uma propriedade comum é um ponto de vista válido a ser adotado. Isso também tornaria a existência de escalares NumPy específicos mais fácil de explicar. Mas eu não vi nenhuma apresentação do NumPy que tenha esse ponto de vista.

@rgommers

Os administradores do (s) supercomputador (es) que você usa realmente deveriam conversar uns com os outros, certo?

Não. Eles nem sabem sobre a existência um do outro. Eles trabalham para diferentes organizações em diferentes lugares, cuja única semelhança é ter alguns usuários em comum.

Eu não quis dizer que você deve educar 80% de todos os administradores de sistemas em todo o mundo, apenas aqueles que você precisa.

Não se trata de mim - eu tenho uma solução que funciona perfeitamente bem para mim: sempre instalo o Python e todas as bibliotecas do código-fonte, no meu diretório inicial.

Trata-se de pessoas com quem colaboro e pessoas que me pedem ajuda (por exemplo, porque participaram de um de meus cursos de Python no passado). Eles não têm competência técnica para gerenciar sua própria instalação do Python e encaminhar para outra pessoa (administrador ou colega mais experiente).

para aprender como os números de versão no mundo real realmente funcionam

Na cultura de fundo compartilhada das pessoas em quem estou pensando, o mundo real realmente funciona como uma versão semântica, ou uma aproximação.

Na cultura de fundo compartilhada das pessoas em quem estou pensando, o mundo real realmente funciona como uma versão semântica, ou uma aproximação próxima.

Isso porque eles usam um número limitado de bibliotecas, principalmente lentas como LAPACK & co. Como @njsmith apontou, a maioria dos softwares tem números de versão baixos porque eles não usam versionamento semântico.

@rgommers Eles usam principalmente bibliotecas lentas, embora eu não diria "um pequeno número".

Como @njsmith apontou, a maioria dos softwares tem números de versão baixos porque eles não usam versionamento semântico.

Não na minha experiência. Mas então, "maioria" provavelmente significa "muitos daqueles que eu conheço", tanto para você quanto para mim, e provavelmente há pouca sobreposição entre os pacotes que você usa e os que eu uso, fora do ecossistema SciPy.

E presumivelmente, se fizéssemos essa mudança, você passaria para o SciPy porque é o próximo bit de infraestrutura? Quando deixa de ser infraestrutura?

Eu realmente preferiria que SciPy e todo o resto dos fundamentos do ecossistema SciPy adotassem os mesmos princípios, mas pessoalmente não vou investir nenhum esforço em argumentar por isso em qualquer outro lugar do que NumPy, que é muito mais amplamente usado do que qualquer um as outras bibliotecas, e também muito mais fundamentais. Os arrays NumPy são a estrutura de dados central para muitos softwares científicos, enquanto o SciPy é apenas uma enorme coleção de funções das quais qualquer aplicativo usa um pequeno subconjunto.

Observe também que o SciPy de facto usa versões semânticas, embora provavelmente não intencionalmente, porque acabou de chegar a 1.0.

E por que o NumPy e os outros bits de infraestrutura desejam ter um esquema de versão completamente diferente do próprio Python e do resto de todo o ecossistema científico do Python?

Todo o ecossistema da SciPy deve, de fato, usar a mesma abordagem, aquela que é (a meu ver) a dominante na computação científica. Isso não se aplica a bibliotecas Python e Python de outros domínios, que têm hábitos diferentes. O desenvolvimento da Web, por exemplo, é muito menos conservador do que a computação científica. Também é feito principalmente por pessoas diferentes, que cuidam de usuários diferentes. A linguagem Python seria o único ponto de contato.

Os arrays NumPy são a estrutura de dados central para muitos softwares científicos, enquanto o SciPy é apenas uma enorme coleção de funções das quais qualquer aplicativo usa um pequeno subconjunto.

E a estrutura de dados central é estável. A grande maioria das mudanças incompatíveis em qualquer versão são casos esquivos e principalmente não no comportamento ndarray. Consulte https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes por exemplo. Observe também que nenhuma dessas mudanças teria qualquer significado para um administrador de sistema, então, mesmo que eles olhassem para essas notas por um longo tempo (se fosse 2.0.0), eles não seriam capazes de decidir se uma atualização estava ok ou não.

Observe também que o SciPy de facto usa versões semânticas, embora provavelmente não intencionalmente, porque acabou de chegar a 1.0.

SciPy usa exatamente o mesmo esquema de versão e política de depreciação / remoção que o NumPy. Estar em 0.x por um longo tempo não implica sempre.

aquele que é (a meu ver) o dominante na computação científica

As comparações tradicionais do ecossistema SciPy são com coisas como Matlab e R. Não consigo encontrar nenhuma informação sobre R, mas está em 3.xe evoluiu muito, então provavelmente nunca. Matlab: definitivamente não é sempre.

RE: indexação sofisticada. Na verdade, isso poderia usar uma função dedicada. Isso é o que foi feito no TensorFlow, por exemplo, com tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask , etc. O resultado é um pouco mais detalhado do que sobrecarregando [] , mas certamente mais transparente.

Outro recurso que pode ajudar são as anotações de tipo, um recurso que foi parcialmente motivado pela dificuldade da transição do Python 2 para 3.

Não estou dizendo que isso seria fácil. Na minha opinião, as consequências para a comunidade são mais importantes. Isso realmente levaria muita energia para implementar e, em seguida, empurrar para projetos como o SciPy.

@khinsen Tenho acompanhado a discussão a semana toda e acho que tenho um problema de teste prático para testar sua opinião sobre o assunto. Este pode ser um bom item para ver como sua perspectiva lidaria com esses conflitos, em vez da discussão levemente abstrata até agora.

Atualmente, graças ao framework Apple Accelerate, a versão mínima exigida do LAPACK é 3.1.ish, que é de mais de uma década atrás. E atualmente o LAPACK está em 3.8.0. Nesse ínterim, eles descartaram várias rotinas (obsoletas e / ou removidas) e corrigiram muitos bugs e, o mais importante, introduziram novas rotinas que são necessárias para preencher a lacuna entre o software comercial e o software científico Python. O resultado final está resumido aqui . Tenho incomodado constantemente, principalmente @rgommers e outros nos últimos 6 meses, por causa disso 😃 e posso garantir que se eles fossem o tipo de pessoa que você, talvez a contragosto, retratou aqui, isso já deveria ter acontecido e quebrado o código de muitos pessoas. Em vez disso, eles explicaram pacientemente por que não é tão fácil abandonar o suporte do Accelerate.

Agora, há uma necessidade incontestável de versões mais recentes. Essa não é a discussão e podemos pular essa parte com segurança. Há uma porção significativa de usuários do NumPy e do SciPy que se beneficiaria com isso. Mas não podemos simplesmente abandoná-lo por causa dos argumentos que você já apresentou. Como você resolveria isso?

Não estou perguntando isso de uma forma sarcástica, mas como todos os desenvolvedores parecem pensar da mesma forma (e devo dizer que concordo com eles), talvez seu visual possa dar uma ideia nova. Devemos manter o Accelerate e criar um novo pacote NumPy / SciPy toda vez que isso acontecer? Se deixarmos de apoiar para inovar, qual a melhor forma que você acha de chegar aqui?

Atualmente, graças ao framework Apple Accelerate, a versão mínima exigida do LAPACK é 3.1.ish

@mhvk , isso pode ser um problema para # 9976 em 1,14, que acho que precisa de 3.2.2 (editar: vamos mover a discussão para lá)

@xoviat : Vamos discutir esse assunto

@ilayn Obrigado por

O principal ponto comum: existem diferentes usuários / comunidades com diferentes necessidades. Alguns querem o Accelerate, outros querem os novos recursos do LAPACK. Ambos têm boas razões para suas prioridades específicas. Pode até haver pessoas que desejam os recursos do Accelerate e do LAPACK, embora isso não esteja claro para mim.

No mundo Fortran / C, esse problema não existe porque as pilhas de software são mais rasas. Existem Fortran, LAPACK e o código do aplicativo, sem intermediários adicionais. O que acontece é que cada código de aplicativo escolhe uma versão particular do LAPACK dependendo de suas prioridades. Centros de computação normalmente mantêm várias versões de LAPACK em paralelo, cada uma em seu próprio diretório, a escolha sendo feita modificando o código do aplicativo Makefile .

A lição que podemos e devemos aprender no ecossistema SciPy é que escolher as versões do software não é tarefa dos desenvolvedores de software, mas das pessoas que montam pacotes de software específicos para aplicativos. Em nosso mundo, são as pessoas que trabalham no Anaconda, Debian e outras distribuições de software, mas também gerentes de sistemas em vários níveis e usuários finais com a competência e motivação certas.

Portanto, minha proposta para o dilema SciPy / LAPACK é manter o SciPy de hoje usando o Accelerate, mas colocá-lo no modo de manutenção mínima (possivelmente assumido por pessoas diferentes). As pessoas que desejam o Accelerate podem escolher "SciPy 2017" e ser felizes. Eles não receberão os novos recursos do LAPACK, mas presumivelmente isso está bom para a maioria deles. O desenvolvimento continua em um novo namespace ( scipy2 , scipy2018 ou qualquer outro), que muda para o LAPACK moderno. Se tecnicamente possível, permita a instalação paralela dessas duas (e futuras) variantes (o que eu acho que deveria ser possível para o SciPy). Caso contrário, as pessoas que precisam de ambos terão que usar vários ambientes (conda, venv ou ambientes de todo o sistema via Nix ou Guix). Observe que, mesmo neste segundo cenário, eu recomendo fortemente alterar o namespace com cada alteração incompatível, para garantir que os leitores do código Python em qualquer nível entendam para qual versão SciPy o código foi escrito.

A ideia geral é que os desenvolvedores proponham coisas novas (e se concentrem em seu desenvolvimento), mas não as anunciem como "melhores" em um sentido geral, nem como uma substituição universal. Escolher a combinação certa de versões de software para uma tarefa específica não é trabalho deles, é de outra pessoa.

A ideia geral de que o desenvolvimento e a montagem são feitos de forma independente e por pessoas diferentes também sugere que os mega pacotes de hoje devem ser divididos em unidades menores que podem progredir em taxas diferentes. Não há razão hoje para o NumPy conter uma pequena interface LAPACK e ferramentas como f2py . Para SciPy, pode fazer sentido ter um namespace comum indicando coerência e uma política de desenvolvimento comum, mas os subpacotes podem ser distribuídos de forma independente. A abordagem do mega-pacote remonta ao lema "baterias incluídas" do Python, que era ótimo há 20 anos. A base de usuários de hoje é muito diversificada para isso, e o pacote de software geralmente é reconhecido como uma atividade distinta. Incluir as baterias agora deve ser tarefa do Anaconda.

O principal obstáculo para adotar tal abordagem são as distribuições Linux tradicionais, como Debian ou Fedora, com sua abordagem "uma instalação Python por máquina". Acho que eles poderiam mudar para vários ambientes virtuais de todo o sistema com um esforço razoável, mas não pensei muito sobre isso. Para mim, o futuro do empacotamento de software são sistemas baseados em ambiente, como conda ou Guix.

Não vejo como todas as preposições que você apresentou até agora são compatíveis com qualquer uma dessas etapas

• Você acabou de recriar a loucura da imagem a seguir
  
  Acabei de contar e agora tenho 27 cópias na minha máquina Windows. Agora multiplique isso por 10 desde (lançamentos são mais frequentemente aqui) e por 2 (desde que os ciclos de lançamento do NumPy e SciPy são independentes). No ano de 2025, terei facilmente 15 cópias de cada biblioteca e 10 LAPACKs e 5 f2pys como dependências. Sem falar da carga de manutenção de apenas um grupo de dezenas de pessoas em ambos os pacotes, isso simplesmente não funciona. (C ++ não é relevante, insira qualquer biblioteca padrão de qualquer coisa). Peça Win a qualquer desenvolvedor de código comercial e diga que essa é uma boa ideia. Não sou responsável pelo que se segue nessa troca.
• Em seguida, você aumentou a granularidade dos pacotes e agora todos fazem as coisas por conta própria com diferentes versões de pacote; O f2py quebrou algo em uma versão, então o SciPy para de compilar na próxima, mas ainda depende da versão anterior do NumPy. Portanto, alguma entidade holística deve reuni-los gratuitamente.
• Então você também fez da Anaconda (ou alguma outra entidade) uma empresa de grande dependência, assim como a Accelerate era. Ou simplesmente haverá uma abundância de "outras pessoas".
• Em seguida, você mobilizou a maior parte da base de usuários em um fluxo de trabalho que eles realmente não querem (eu incluído) envolvendo envs virtuais.
• Então você até modificou os sistemas operacionais Linux de passagem (o que é ... quero dizer, apenas ler algumas listas de discussão deles, é divertido).

Talvez você tenha divagado um pouco.

(Esta se tornou uma discussão aberta para todos, então vou prosseguir e pular).

O problema em manter o suporte para aceleração não é que ele não tenha APIs LAPACK mais recentes. Se esse fosse o problema, poderíamos enviar calços LAPACK mais novos e pronto. O problema é que existem funções básicas que retornam resultados incorretos em determinados cenários. Não há outra maneira de contornar isso a não ser escrever nossas próprias funções BLAS. E se estivermos fazendo isso, podemos também exigir OpenBLAS ou MKL.

@xoviat Tudo isso foi discutido em https://github.com/scipy/scipy/pull/6051. Como sempre, nunca é tão simples. Mas o objetivo não é discutir a eliminação do Acelerar, mas usá-lo como um caso de uso para o ciclo de desenvolvimento real para novas versões.

@ilayn Sim, tenho certeza que já sei sobre os pontos que estou fazendo. Mas o comentário era para @khinsen; Acho que ele tem a impressão de que podemos realmente manter o suporte do Accelerate.

Alguém poderia argumentar que uma característica (ou limitação) do ecossistema Python é que você obtém uma versão de uma biblioteca sem o horrível hack de mutilar nomes. Isso acontece no núcleo do Python. É por isso que existem bibliotecas chamadas _lib_ e _lib_ 2 que têm a mesma finalidade, mas diferenças de API. Até mesmo o Python funciona dessa maneira. Não é possível misturar bibliotecas padrão entre versões, mesmo que ambas sejam tecnicamente utilizáveis ​​no Python moderno, sem que alguém as copie e coloque no PyPi. Há muitas perguntas StackOverflow sobre isso, todas com a mesma conclusão.

@ilayn Se por algum motivo você quiser ter todas as combinações possíveis de todas as versões de tudo em sua máquina, sim, isso é uma bagunça. Mas por que você quer isso? Se você se limitar às combinações de que realmente precisa para seus cenários de aplicação, aposto que será menos. Como exemplo, mantenho exatamente dois ambientes Python em minha máquina: um com Python 2 + NumPy 1.8.2 para executar meu código de 20 anos e um representando o estado da arte de cerca de dois anos atrás para todo o resto ( dois anos atrás porque eu o configurei há dois anos e nunca vi um motivo para atualizar depois disso).

Quanto à granularidade, talvez eu não tenha sido muito claro em minha proposição. O que eu defendo é mais granularidade na embalagem, não no desenvolvimento. Eu esperaria que o desenvolvimento de, digamos, f2py e SciPy continuasse em estreita coordenação. f2py-2018 e SciPy-2018 devem funcionar juntos. Isso não significa que eles devem ser embalados como uma única entidade. O objetivo é fornecer mais liberdade para os gerentes de distribuição de software fazerem seu trabalho.

Definitivamente, não quero tornar o Anaconda ou qualquer outra distribuição uma dependência. É mais como a "abundância de outra pessoa", embora eu não espere que o número de distribuições aumente para "abundância", visto que montá-las dá muito trabalho.

Não tenho ideia de qual fluxo de trabalho "a base de usuários" deseja. Vejo muitas bases de usuários diferentes com requisitos diferentes. Pessoalmente, eu escolheria vários ambientes, mas se houver uma base significativa de usuários que deseja um único ambiente por máquina, alguma distribuição cuidará disso. Mas os ambientes virtuais foram inventados por uma razão, eles resolvem um problema real. Distribuições de nível de sistema como Nix ou Guix os levam a outro nível. Eu não espero que eles desapareçam.

BTW, na verdade estou seguindo a lista de discussão de uma distribuição Linux (Guix). Não é muito divertido, mas muito trabalho duro e prático. Estou feliz que haja pessoas fazendo isso.

@xoviat Eu não sugeri "manter o suporte do Accelerate". Eu apenas sugiro manter uma variante do SciPy (praticamente a atual) por perto, não como uma versão desatualizada para o museu, mas como uma variante de interesse para um grupo de usuários em particular: aqueles para quem usar o Accelerate é mais importante do que resolver os problemas que Acelere cria para outros. As pessoas que "aceleram primeiro" terão que conviver com as consequências de sua escolha. Alguns problemas nunca serão resolvidos para eles. Provavelmente não há problema para eles ("bugs conhecidos são melhores do que bugs desconhecidos"), então por que forçá-los a algo diferente?

É realmente tudo sobre rotulagem e comunicação. Eu quero me afastar da imagem idealizada de software seguindo um caminho linear de progresso, com versões mais novas sendo "melhores" conforme indicado por números de versão "maiores". Quero substituir essa imagem por uma que considero mais realista: não há uma relação de ordem óbvia entre os lançamentos de software. Aqueles produzidos por uma comunidade de desenvolvedores coerente e duradoura têm uma ordem temporal, mas isso não implica nada sobre qualidade ou adequação para qualquer aplicativo.

Se a imagem idealizada estivesse certa, não veríamos garfos e não teríamos ambientes virtuais. Nem projetos como o VersionClimber .

O que estou propondo é que os desenvolvedores de software devam abraçar essa realidade em vez de negá-la. Devem desenvolver (e, acima de tudo, embalar e rotular) seus produtos para um mundo de diversidade.

@khinsen Se você concorda com resultados incorretos de funções de álgebra linear, podemos manter o suporte de aceleração (nota para os outros: eu sei como fazer isso). No entanto, o principal problema é que você pode ser a única pessoa que deseja isso. E mesmo se você não estiver, o que acontece quando alguém na estrada culpa o SciPy por um problema com aceleração? O que acontece quando alguém quer ter seu bolo e comê-lo? Eu posso ver isso acontecendo.

@xoviat Não, não estou bem com resultados incorretos de funções de álgebra linear. Mas tenho certeza de que muitos usuários do SciPy não precisam das funções afetadas. No tópico ao qual você se referiu, alguém sugeriu remover / desativar as funções afetadas quando o Accelerate for detectado, o que eu acho uma boa solução (nota: não posso julgar o esforço necessário para implementar isso).

De certa forma, isso é parte do problema do mega-pacote. Com uma distribuição mais granular, seria mais fácil escolher o que funciona, tanto no desenvolvimento quanto no nível de montagem de distribuição. Alguém poderia até imaginar um montador de distribuição compondo uma distribuição SciPy específica de domínio e plataforma na qual diferentes subpacotes usam diferentes versões do LAPACK, por exemplo, para uso em contextos HPC.

Mas tenho certeza de que muitos usuários do SciPy não precisam das funções afetadas.

Há evidências mínimas para essa afirmação e eu de fato apostaria no oposto. As funções são amplamente utilizadas, mas só falham em determinados cenários; em outras palavras, seus resultados provavelmente estão corretos, mas podem não estar. Sim, isso provavelmente se aplica ao SciPy que você instalou atualmente, se estiver usando o OSX. Sim, isso precisa ser corrigido.

No que diz respeito a manter um branch separado, não acho que alguém se oporia a lhe dar acesso de escrita a um branch específico para você manter. Mas este é um software de código aberto e as pessoas trabalham no que desejam; Não acredito que muitas pessoas estariam interessadas em manter esse ramo.

Na verdade, eu acho que o anaconda SciPy é compilado com MKL, então você não seria afetado nesse caso. Mas então por que você se preocuparia em acelerar o suporte?

@xoviat Parece que há um grande mal-entendido aqui. Não tenho nenhum interesse pessoal nesta questão específica. Eu não uso nenhuma rotina de álgebra linear do SciPy.

Você apontou para um tópico sobre um problema do SciPy e perguntou como eu lidaria com esse tipo de situação. O tópico mostra claramente relutância em simplesmente descartar o suporte do Accelerate, do qual deduzi que há um grupo de usuários significativo que seria afetado por tal mudança. Se esse grupo de usuários não existe, onde está o problema? Por que o SciPy ainda não abandonou o suporte do Accelerate?

@xoviat Manter um branch separado é fácil para qualquer pessoa. Não há necessidade de hospedá-lo no mesmo repositório GitHub. Em outras palavras, os ramos não são o problema. O problema é o namespace, para tornar a existência paralela de versões SciPy separadas transparente para os usuários (e montadores de distribuição).

Hoje, quando você vê o código dizendo "import scipy", não tem ideia para qual intervalo de versões do SciPy ele deve funcionar (ou seja, foi testado até certo ponto). Na melhor das hipóteses, há um README dizendo "SciPy> = 0.8" ou algo parecido. Este hábito é baseado na suposição de que versões "superiores" são sempre "melhores" e nunca degradam (quebram, diminuem a velocidade, ...) nada. E essa suposição está simplesmente errada.

Se, por outro lado, o código diz "import scipy2017 as scipy", então é claro para todos os leitores que usá-lo com versões anteriores ou posteriores pode levar a surpresas ruins. E se as versões antigas do SciPy desaparecerem (efetivamente, por falta de manutenção), esse código falhará com uma mensagem de erro, em vez de continuar a funcionar de forma não confiável.

Este é o único ponto que estou tentando fazer neste tópico. A coexistência de diferentes versões é uma realidade. A ideia de que quanto mais alto melhor é um sonho. Sejamos realistas e nos organizemos para o mundo real, reconhecendo um universo de múltiplas versões e ajustando a comunicação de todos para evitar mal-entendidos.

Bem, não sei ... na minha opinião quando se trata de avisos, uma importação de versão específica não é um aviso, é proibitivo usar uma versão diferente, já que os usuários com problemas como você descreveu não ousarão alterar seu código. Um aviso seria se você imprimir um aviso na instalação / tempo de execução, informando que não foi testado para todas, exceto para as versões específicas.

Suponho que seja possível criar esse tipo de pacote extra. Também espero que isso apenas crie um tipo diferente de inferno. Muito pode sobreviver, mas a verificação de tipo, por exemplo, não vai e não pode quando você mistura duas versões, então basicamente você não saberá se pode ou não funcionar até que você tente (e ninguém vai testar isso!).
E a menos que você esteja sugerindo permitir a mistura de duas versões, acho que sua solução scipy2017 só vai piorar as coisas. Parece mais que precisaríamos de algo como um ambiente virtual dinâmico / runtime (como pin_import_version("1.6<numpy<1.10", level="raise") antes de qualquer importação no nível python).

A importação específica faz sentido se você tiver grandes mudanças proibitivas (um pouco como py2 / py3), e já vimos que temos opiniões diferentes sobre onde ou em que escala de tempo essa linha "principal" parece estar.

A compatibilidade com versões anteriores NEP # 11596 foi enviada, podemos fechar isso?

A compatibilidade com versões anteriores NEP # 11596 foi enviada, podemos fechar isso?

Sim, podemos fechar isso. Independentemente desse NEP (que menciona explicitamente o semver como uma alternativa rejeitada), o consenso dos desenvolvedores principais aqui é que não queremos mudar para o semver. Portanto, fechando como wontfix.

Obrigado a todos pela discussão.