Pandas: DEPR: limpar a lista de descontinuações de versões anteriores

Apenas para sua informação, cols é usado em to_csv e to_excel também.

@TomAugspurger bom ponto!

@jsexauer você faria outro PR para depreciar cols em to_csv / to_excel (por exemplo, faça o que você fez no pivô, ainda aceite, mas forneça o aviso e substitua columns )

Claro sem problemas.

@jreback Eu estava pensando, agora que também estamos depreciando isso em to_csv e to_excel , não deveríamos manter esse ciclo de depreciação por mais de um lançamento? Porque não sei se a maioria dos usuários atualiza sua versão a cada lançamento.

Eu concordo com @jorisvandenbossche - dar um ciclo de lançamento adicional como buffer seria prudente.

certamente
apenas mantendo os problemas em aberto como lembretes
Acabei de remover a sintaxe antiga em um tipo que acho < 0.8!

embora talvez os altere para dizer 0,16, então estão no ponto correto

Adicionei seções por versão ao post original. Vamos manter isso como o problema de suspensão de uso em execução (a menos que haja objeções. Estou aberto a problemas específicos por versão)

@jsexauer quer fazer um pr para os indicados para 0.15.0

Certeza vai fazer

Existem algumas reprovações no categórico, o que resultará em testes de unidade com falha.

Talvez essa seja uma boa maneira de rastrear essas depreciações:

# in testing.py
def fail_after_whatever_comes_first(date, pandas_version):
     from dateutil import parser
     import datetime
     latest = parser.parse(date)
     self.assertFalse(datetime.now() >= latest)
     self.assertFalse(LooseVersion(pd.__version__) >= pandas_version)

e, em seguida, use isso como o último teste nos unittests para métodos/propriedades/argumentos obsoletos

@JanSchulz o que você está sugerindo aqui?

Minha sugestão foi colocar o tratamento de depreciação no próprio código e não em um relatório de bug :-)

colocar o código real não é uma boa ideia (se for o ÚNICO lugar) e, em geral, apenas atrapalha as coisas. Você precisa ter alguma maneira de rastrear algo que ocorreria (com um lembrete explícito), portanto, um problema é MUITO melhor e como o fazemos.

@jsexauer alguma entrega para 0.15.0? (ou edite o topo e vá para 0,16)

@jreback Eu escrevi o código, mas está falhando nos testes de unidade agora. Preciso voltar e descobrir se os testes precisam ser atualizados ou se eu removi as descontinuações incorretamente. Você tem uma linha do tempo em que gostaria que as mudanças fossem feitas?

@jsexauer quais são as mudanças que você tem funcionando parcialmente?

Aqui está o ramo em que eles estão: https://github.com/jsexauer/pandas/tree/fix6581_015
Aqui está o relatório de falha do teste de unidade: https://travis-ci.org/jsexauer/pandas/jobs/35994074

ahh ok, que tal fazermos o delevel e mover o boxplot para 0.16.0 então

@TomAugspurger , @jorisvandenbossche

@jsexauer quer apenas colocar um PR para o delevel?

@jsexauer vamos empurrar isso para 0,16 (embora eu aceite uma remoção de nível agora, se você puder)

Vou escrever um bem rápido e enviá-lo dentro de uma hora

@jsexauer gr8 obrigado. Por favor, edite os problemas acima e mova para 0.16.0 os 0.15.0 restantes

Eu ia começar a trabalhar nas depreciações de 0,16 em breve. Queria fazer check-in e ver se você ainda queria que tudo o que está listado em 0.16 fosse obsoleto. @jreback

Eu acho que tudo na lista é bom para ir.

Atualizei todos os problemas a serem obsoletos. Acho que qualquer coisa <= 0.14.0 deve ser feita em 0.17.0. Todos requerem menções na seção Previous Deprecations . Alguns podem precisar de uma nota doc se for 'importante' o suficiente (por exemplo, isso foi removido na versão ???) e/ou menção mais proeminente no whatsnew (por exemplo, nos highlites)

Ok com fazer os 0.15.0 para ser honesto também.

qualquer pessoa interessada em colocar um PR para qualquer uma dessas remoções de descontinuação. Qualquer coisa < 0,14 está ok com certeza. qualquer outra coisa pls lmk.

@TomAugspurger

podemos fazer um PR para isso? (primeiro em cima)

 boxplot #7096 (0.14.0)
 change default of return_type from None to 'axes'
 update return_type section in visualization.rst

Com certeza, farei um PR hoje à noite ou domingo.

Atualizei a lista no topo, e há algumas descontinuações de 0.15 que podem ser removidas em 0.19.0 (e algumas de 0.16.0 talvez também valham a pena considerar)

@jorisvandenbossche , @jreback : O que as remoções de descontinuação "talvez" representam? São aqueles que poderiam ser feitos em 0.19.0 mas não são necessários? Ou que ainda não temos certeza sobre eles?

Acho que vamos tentar priorizar os que estão marcados para 0.19.0, depois fazer os talvez se possível (e outros caso a caso).

Pouco confuso com o que está acontecendo com a depreciação de operações do índice '+' / '-'. Além de remover todos os avisos, essas operações estão apenas sendo reaproveitadas para fazer adição / subtração aritmética -> a mudança é apenas uma alteração de API para fazer operações aritméticas? Ou essas funções estão sendo removidas? Meu palpite é o primeiro, mas eu queria esclarecer.

@jreback , @jorisvandenbossche : você pode marcar a remoção de depreciação flavor nesta lista agora que #13611 foi mesclado!

Além disso, apenas curioso, algum motivo pelo qual estamos removendo SparsePanel agora?

bem SparsePanel está causando alguns avisos de depreciação addtl que são irritantes.

@jreback : Você poderia marcar a caixa return_type='frame'|'series' na lista "talvez"? Meu PR para remover isso foi mesclado há alguns dias (# 13701).

Outro detalhe: o #13735 de @jorisvandenbossche deve ser movido para a seção For 0.19.0 IINM (não "Future Release")

Pouco confuso com o que está acontecendo com a depreciação de operações do índice '+' / '-'. Além de remover todos os avisos, essas operações estão apenas sendo reaproveitadas para fazer adição / subtração aritmética -> a mudança é apenas uma alteração de API para fazer operações aritméticas? Ou essas funções estão sendo removidas? Meu palpite é o primeiro, mas eu queria esclarecer.

Sim, de fato, com o propósito de ser operações aritméticas. Se você tiver tempo para fazer um PR, seja sempre bem-vindo :-)

@jreback : Para a seção 0.17, generate_bq_schema não está mais na base de código. Provavelmente removido na migração para pandas-gbq ?

@gfyoung

Para a seção 0.17, generate_bq_schema não está mais na base de código. Provavelmente removido na migração para pandas-gbq?

marcou

@jreback , @jorisvandenbossche : Algo sobre a política de remoção de descontinuação pode ser adicionado na edição original? Isso pode ser útil caso alguém queira trabalhar nessa frente (por exemplo, quantas versões a depreciação precisa ter antes de ser removida?)

Boa ideia. Acho que atualmente removemos as reprovações de, por exemplo, 0,17 em 0,20. Isso significa que mantemos as deprecações por 3 lançamentos (descontinuação em 0.17 -> avisos em 0.17, 0.18, 0.19 -> alterado em 0.20) ?

Sim, três versões principais de volta... isso é IINM correto.

@jorisvandenbossche : Queremos continuar mudando a versão do marco a cada vez? Sua chamada.

Não dá muito trabalho mudar isso :-)
Eu colocaria nesse marco, então fica claro que há trabalho aqui a ser feito para esse lançamento. Uma vez que tudo para essa versão é feito, ou quando é hora de rc e não colocamos mais depreciações, nós apenas mudamos para a próxima versão.
Vejo que @jreback o colocou em um marco "Admin", mas acho que o fluxo de trabalho descrito acima está OK?

@jorisvandenbossche : Este fluxo de trabalho funciona comigo. Está muito mais claro agora quais reprovações precisam ser resolvidas e quando (espero que outros concordem! 😄)

@gfyoung FYI, quero ver quando descontinuamos pd.options.line_width/height . Eles podem ser removidos (em 0.21.0) tenho certeza

@jreback : Você está absolutamente certo. 0,11 e 0,12 respectivamente. 😢

se alguém estiver interessado pode remover qualquer um dos .17/.18/.19 em 0.22

Observar algumas funções/métodos não atingidos nos testes pode merecer consideração:

indexing.is_index_slice
Block.reindex_axis
_most_ de SingleBlockManager.reindex

@jbrockmendel : Pode merecer consideração? Absolutamente! Todos estes são obsoletos embora? Não vejo todos na lista. Eu definitivamente gostaria de garantir que os não obsoletos obtenham mais cobertura, se possível.

cc @gfyoung atualizei para remover a maioria dos 0.20.0

Eu não acho que já devemos remover coisas obsoletas em 0.20. Eu sei que aumentamos de 0,22 para 0,23, mas para reprovações não acho que precisamos ver o 0,22 lançado como um "lançamento importante" nesse sentido (já que não tem novos recursos e, em princípio, não deve atrasar 0,23).
0.20 foi lançado apenas em maio de 2017, portanto, essas descontinuações não terão nem um ano.

Hmm... justo. Eu só comecei porque notei que @jreback havia movido um monte abaixo de 0.23 .

não, precisamos mover a agenda para cima
caso contrário, adiciona muitas coisas em uma única versão

não, precisamos mover a agenda para cima

@jreback : Então... retome a remoção de coisas obsoletas de 0.20.0 ? Vejo que o problema original não foi modificado desde que @jorisvandenbossche o alterou.

@jreback você não estava sendo totalmente claro, posso interpretar "não há necessidade de mover o cronograma" como "não há necessidade de já começar a remover as coisas de 0,20". Mas acho que foi você quem marcou essas depreciações de 0,20 como prontas para remoção?

@jorisvandenbossche sim, eu mudei isso. Não vejo motivo para esperar para removê-los (exceto alguns que marquei especificamente). se você tem aqueles que você acha que não devem ser removidos até 1.0, então, por favor, mova-os para onde está o ix/Panel.

Como eu disse acima, acho que nenhuma das reprovações de 0,20 deve ser removida em 0,23 (falando sobre aquelas na primeira lista de 0,20, então não sobre ix/Panel). IMO, eles só devem ser removidos na próxima versão principal, seja 0.24 ou 1.0, isso realmente não importa.

Nossa regra implícita tem sido manter a depreciação no mínimo para dois lançamentos principais (mas talvez devêssemos documentar essa expectativa de forma mais explícita) e, ao contar esses lançamentos principais, não acho que deveríamos contar 0,22. Essas reprovações não terão nem um ano de idade quando o 0.23 for lançado.

Acho que não devemos contar 0,22. Essas reprovações não terão nem um ano de idade quando o 0.23 for lançado.

Acordado com @jorisvandenbossche. O que mais importa para as bibliotecas downstream é o tempo de calendário entre a depreciação de algo e sua remoção. Como a versão 0.22 acelerou nosso cronograma de lançamentos, acho que devemos adiar a remoção de coisas programadas para 0.23.

e o 1 atm em questão foi preterido em 0,19
então deve ser removido agora

se você quiser avançar na limpeza das coisas e estendê-las, a remoção de reprovações é muito importante

@TomAugspurger : a depreciação feita em # 16617 ... parece que foi removida em algum momento? Isso ainda está em pauta para remoção em 0.25.0 ou o plano mudou?

@gfyoung o PR que você linkou nunca foi mesclado?

@jorisvandenbossche : Bom ponto - oops 🙂. Nesse caso, parece que não removeremos isso tão cedo. Dito isto, minha pergunta ainda permanece em relação a uma futura depreciação e remoção desses métodos.

Dito isto, minha pergunta ainda permanece em relação a uma futura depreciação e remoção desses métodos.

Toda a classe SparseSeries está sendo preterida, então não acho que haja necessidade de depreciar ainda mais um determinado caso em seu construtor.
Há DataFrame.sparse.from_spmatrix agora para fazer isso.

Observe que eu fixei isso no GH depois do nosso bate-papo DEV ontem. Acredito que queremos realmente remover qualquer coisa que tenha sido preterida antes da versão 1.0 para nossa versão 1.0, portanto, os PRs da comunidade certamente seriam bem-vindos

@mroeschke seria conveniente para você remover o #20584?

Com certeza @jbrockmendel. Pode fazer.

@mroeschke lidera isso e 13777 estão se comportando mal com várias edições em um curto período de tempo. neste caso, acho que reverteu silenciosamente a edição rolling.apply que você fez

Obrigado pelo aviso @jbrockmendel. Vamos ver se a segunda vez é um encanto.

@TomAugspurger você tem vantagem comparativa em #23767?

@mroeschke IIRC #22644 era seu, quer terminar?

@WillAyd você já não cuidou do #18731? em caso afirmativo, atualize as listas de caixas de seleção

@pandas-dev/pandas-core Alguns deles são ambíguos e podem precisar de discussão/esclarecimento:

• [ ] #18347 .add_suffix/.add_prefix - a discussão lá faz parecer que isso pode não ser obsoleto afinal. Podemos confirmar o status disso?
• [ ] #21930 Series.compress - remover isso quebra np.compress(series) . Nós nos importamos?
• [ ] #27112 Series.item & Index.item - houve alguma discussão recente sobre a não depreciação de item . Onde pousamos nisso?

• +1 ao reativar .item()
• +0 ao descontinuar .add_suffix/.add_prefix, o IIRC não acredita que tenha sido realmente descontinuado
• ok com a remoção de .compress() não é muito útil de qualquer forma, mesmo em numpy, especialmente para 1-D, onde é apenas indexação.

add_prefix / add_suffix nunca foram preteridos, então não há discussão sobre removê-los. Alguém pode abrir um novo problema (ou encontrar um existente) para discutir mais sobre sua descontinuação, mas como aqui trata-se da remoção de coisas realmente obsoletas, removemos isso da lista acima.

Acho que estou bem com np.compress() quebrando.

Vamos discutir sobre item em https://github.com/pandas-dev/pandas/issues/29250 (sou a favor de pelo menos manter parte dele)

@jorisvandenbossche existem alguns desses que eu tentei e não consegui descobrir. Posso fazer você dar uma olhada ou sugerir alguém que eu deveria incomodar? O primeiro é o how fill_method em resample (precisa de GH ref). O segundo é o de #26403.

O segundo é o de #26403.

Acabei de abrir um PR para esse, veja #29955

Primeiro é como fill_method em reamostragem (precisa de GH ref)

Essa depreciação foi introduzida em https://github.com/pandas-dev/pandas/pull/11841. Isso pode ser sobras que não foram removidas em https://github.com/pandas-dev/pandas/pull/20782

@mroeschke mais alguém que você queira chamar antes de eu ir para a cidade?

@jbrockmendel Provavelmente serei lento em descontinuações esta semana. Vá em frente.

Mudei as descontinuações que estamos fazendo na versão 1.0 para um novo problema: https://github.com/pandas-dev/pandas/issues/30228 (portanto, um problema semelhante a esse para manter um log de descontinuações, mas iniciando um novo para 1.x)

Todas as reprovações listadas foram limpas. Obrigado a todos!