A ideia é que o 0.24.0 seja o último lançamento compatível com py2, certo?

24021 corrige um comportamento de caixa de canto em comparações de carimbo de data/hora, mas também introduz uma inconsistência entre o comportamento py2/py3. #21394 fez a alteração análoga às comparações Timedelta.

A coisa _menos_ consistente que poderíamos fazer é manter o status quo, alterando o comportamento do Timedelta, mas não o comportamento do Timestamp. A questão é a) mesclar #24021 e ter comportamento py2/py3 incompatível em 0.24.0, ou b) reverter #21394 até depois de 0.24.0 e esperar para alterar ambos na primeira versão somente py3.

Inclino-me ligeiramente para a opção b.

A ideia é que o 0.24.0 seja o último lançamento compatível com py2, certo?

Basicamente, embora eu suponha que faremos algum backport e um 0.24.1 ou 2 que suporte py2 também.

Não estou muito familiarizado com esta seção, mas sua opção b parece razoável.

Embora ... eu poderia viver com comportamento inconsistente py2 / py3. E seríamos consistentes com o edifício? Isso não seria o único.

Pergunta: com
https://github.com/pandas-dev/pandas/pull/24021 seríamos consistentes com o timedelta embutido de cada versão?

Esta versão é realmente grande, mas a v.0.24 também é bastante especial porque definirá efetivamente a API 1.0 (no sentido da política de não depreciação entre 0.24 e 1.0), e também devido à magnitude de todo o esforço do EA obviamente .

Mas - apesar de muito trabalho duro - o estado atual ainda parece um pouco incompleto:

• O refator de data e hora: https://github.com/pandas-dev/pandas/projects/4#card -15359769
• ExtensionArray: https://github.com/pandas-dev/pandas/issues?q=is%3Aissue+is%3Aopen+label%3AExtensionArray , incluindo vários pontos relacionados à funcionalidade principal como __setitem_ (#24020) ou merge (#23020) ou interação entre EAs e outros objetos (pandas) (#22962 / #22974), groupby (#22861) etc.
• regressões: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression
• pd.Array : #23581
• consistência em novos atributos (recomendando .array acima de .values todos os lugares?) #23995
• Por uma questão de consistência (especialmente em relação aos EAs também), acho que deveríamos realmente limpar a API em torno de unique antes de 1.0 (#24108)
• várias outras coisas que estou deixando de fora por brevidade

Realisticamente, um lançamento antes do final do ano significaria um corte em ~ 10 dias no máximo, o que parece irreal no meu ponto de vista, mesmo que cortando cantos.

Dado que a seguinte declaração de @TomAugspurger acima

Basicamente, embora eu suponha que faremos algum backport e um 0.24.1 ou 2 que suporte py2 também.

efetivamente significa mais suporte ao PY2 no início de 2019, acho que se deve considerar não tentar forçar o lançamento antes do final do ano.

Se houver um lançamento antes do final do ano (resp. antes que os problemas mais importantes sejam resolvidos), então concordo especialmente com Tom que será necessário um 0.24.1 para PY2, como 0.24.0 terá muitos problemas (que esperamos que apareçam no RC, mas bem...) para ser o último lançamento, IMO.

Alternativamente (que está simultaneamente mais alinhado com https://python3statement.org/, mas também mais controverso), pode-se considerar ter um último suporte a PY2 0.23.5 este ano e, em seguida, fazer 0.24.0 como somente PY3 Próximo ano...?

@h-vetinari pandas é um projeto voluntário quase completamente. Assim, as prioridades do projeto são definidas por consenso da comunidade e trabalhadas. Temos lançamentos regulares a tempo; 0.24.0 está realmente atrasado por alguns meses. Tentar adicionar coisas adicionais que precisam de discussão não vai acontecer.

O que quer que exista na série 0.24.x é o último lançamento do Python 2, isso foi anunciado há muito tempo. Isto é apenas como é.

Eu não sigo o ponto de
https://github.com/pandas-dev/pandas/issues/24060#issuecomment -444777018. Você poderia tentar reafirmar / resumir?

Eu acho que Py2 vs. Py3 é irrelevante para 0.24.0.

Os problemas relacionados ao EA que você vinculou estão todos indo para 0,24 (não verifiquei todos). Esse é basicamente o bloqueador neste momento, mas não revisei o backlog recentemente.

Eu não tive tempo para olhar para exclusivo.

@jreback

@h-vetinari pandas é um projeto voluntário quase completamente. Assim, as prioridades do projeto são definidas por consenso da comunidade e trabalhadas. Temos lançamentos regulares a tempo; 0.24.0 está realmente atrasado por alguns meses. Tentar adicionar coisas adicionais que precisam de discussão não vai acontecer.

Eu sei tudo isso. Estou apenas dizendo que estar atrasado é uma má razão para apressar um lançamento, se algumas das principais mudanças ainda não foram totalmente desenvolvidas (falando principalmente sobre EA + regressões).

O que quer que exista na série 0.24.x é o último lançamento do Python 2, isso foi anunciado há muito tempo. Isto é apenas como é.

Não sei o que foi discutido em outros canais, mas o que vi no GH foi que a decisão principal foi 0.24->0.25->1.0 . Re: PY2, também foi dito (e há um aviso para esse efeito no whatsnews) que não haverá lançamentos do PY2 após 31 de dezembro de 2018. O suporte à série 0.24.0 para o PY2 é mais ~ 6-8 meses de suportar PY2 (pois o backport para 0,24-branch seria muito complicado). Claro que é uma escolha válida, mas eu só queria sugerir a possibilidade de deixar o PY2 no muito estável 0.23.5.

@TomAugspurger

Eu não sigo o ponto de

24060 (comentário). Você poderia tentar reafirmar / resumir?

Eu acho que Py2 vs. Py3 é irrelevante para 0.24.0.

Desculpe, não ficou claro. Os dois pontos principais (interrelacionados) são:

• não se deve apressar 0,24 devido ao prazo estabelecido (para apoiar PY2) de 31 de dezembro.
  
  
  
  • listei alguns problemas para isso - alguns deles (e muitos outros relacionados que eu não marquei) foram enviados para "Contribuições bem-vindas" em vez de v.0.24
  
  
  • mencionei que 0.24 é especial devido à política de bloqueio de API até 1.0, e que eu acho que isso seria uma pena para .unique (mas entendo que sou uma voz solitária no deserto sobre isso 1)
  
  
• aponte a discrepância entre a caixa de aviso ("A partir de 1º de janeiro de 2019, os lançamentos de recursos do pandas oferecerão suporte apenas ao Python 3") e o suporte à série 0.24 para PY2, juntamente com a sugestão de ter um 0.23.5 para PY2

Os problemas relacionados ao EA que você vinculou estão todos indo para 0,24 (não verifiquei todos). Esse é basicamente o bloqueador neste momento, mas não revisei o backlog recentemente.

A lista de pendências foi reduzida substancialmente recentemente, principalmente por questões sendo enviadas para "Contribuições Bem-vindas" (também para questões de EA). Isso vai para o meu ponto de cortar custos para lançar isso em breve.

Dito isto, sou muito novo neste jogo e não duvido que os desenvolvedores principais tenham a visão geral sob controle - mas apontar uma observação não pode machucar, espero.

Eu não tive tempo para olhar para exclusivo.

Justo, o tempo de desenvolvimento é um recurso muito limitado. Acho que vou ter que tentar convencer todo mundo disso na terra pós-1.0. ;-)

@h-vetinari

Eu sei tudo isso. Estou apenas dizendo que estar atrasado é uma má razão para apressar um lançamento, se algumas das principais mudanças ainda não foram totalmente desenvolvidas (falando principalmente sobre EA + regressões).

Se continuarmos adicionando e adicionando, o lançamento continua sendo adiado para sempre. Eu desenhei uma linha na areia. É assim que você obtém o produto para fora da porta. Assim que o DTA aterrissar totalmente, estaremos em condições de liberar. Então isso não está tão longe. Claro que poderíamos fazer um trabalho extra e apenas dizer que 0.23.5 é o último lançamento do PY2 (e, claro, liberá-lo). Mas será mais fácil voltar para um branch estável, o que significa a série 0.24.x.

Sempre há coisas para adicionar em um lançamento, mas este já é o maior que já tivemos. Existem bugs inevitáveis ​​e, portanto, é melhor fazer mais cedo ou mais tarde. Obrigado por suas contribuições. Não é possível obter todas as principais alterações de API aqui. Você está exatamente certo em que o tempo de desenvolvimento é um recurso realmente limitado.

@jreback
Obrigado pela resposta. Entendo que você queira divulgar isso o mais rápido possível, o que é justo, é claro.

Mas será mais fácil voltar para um branch estável, o que significa a série 0.24.x.

Parece que eu entendi mal que os pandas deixariam de suportar PY2 em 1º de janeiro de 2019 ... Talvez deva adaptar essa caixa de aviso no whatsnews então (" v.0.24.x será a última série que suporta PY2; começando com v.0.25.0 , os pandas serão somente python3"...?)

RE: Progresso do CalendarDay https://github.com/pandas-dev/pandas/pull/22867#issuecomment -445433463

FAÇAM
Adicione todos os avisos de depreciação (prevejo que haverá alguns deles). Isso precisa ser incluído no seguinte:

• Aritmética do tick do dia com outros Ticks, Timedeltas e DatetimeTZ
• DatetimeIndex.shift (somente com reconhecimento de tz)

Migração
O plano é que _Day (anteriormente CalendarDay) substitua apenas o dia assim que o comportamento do dia anterior for substituído.

Preocupação
Durante o último bate-papo do desenvolvedor, houve interesse em que 'D' fosse compatível com argumento/deslocamento de frequência com Timedelta e Datetime. Não vejo uma maneira clara de tornar isso possível sem adicionar muitos patches de macaco.

Exemplo: timedelta_range(..., freq='D'); to_offset('D') retornará _Day no futuro e esse deslocamento precisará incrementar um Timedelta, mas _Day + Timedelta é uma operação inválida.

Alguém tem opiniões sobre o problema de consistência timestamp/timedelta py2/py3?

Várias reprovações estão listadas como A serem removidas na versão 1.0; deve 0.25.0 tomar o lugar de 1.0 para alguns deles?

Alguém tem opiniões sobre o problema de consistência timestamp/timedelta py2/py3?

Você pode resumir essa questão? Idealmente, seguiríamos o python (qualquer versão que esteja sendo executada) aqui, eu acho. Mas acho que não entendi completamente o assunto.

Várias reprovações estão listadas como A serem removidas na versão 1.0; deve 0.25.0 tomar o lugar de 1.0 para alguns deles?

Eu acho que todos eles... Preciso discutir isso, porém, alguns podem precisar ser pressionados.

https://github.com/pandas-dev/pandas/issues/24060#issuecomment -444180736

O Timedelta foi alterado recentemente para retornar NotInplemented no caso de ter gerado anteriormente. Como resultado, seu comportamento py2 corresponde ao python, mas difere do comportamento py3 dos pandas.

Timestamp tem um PR aberto para fazer a mudança análoga.

Uma vez que o py2 é descartado, a mudança está definitivamente correta. Até então, há argumentos de consistência conflitantes.

Devemos obter o Timestamp PR para 0.24.0 ou reverter o Timedelta PR até depois de 0.24.0

(Digitando com os polegares; LMk se não estiver claro)

acho que vamos reverter o Timedelta e, em seguida, empurre os dois para 0.25/1.0 (somente py3)

Movendo este comentário https://github.com/pandas-dev/pandas/pull/24227#issuecomment -446680041 aqui:

(para o qual IMO também precisaremos de pelo menos algumas semanas no mestre)

[Tom] Só para verificar, devemos fazer um release candidate com DatetimeArray o mais rápido possível, certo? E então 1-2 semanas no master enquanto o RC está fora?

Pessoalmente, não, eu não faria isso (se você quer dizer com o mais rápido possível, alguns dias depois). Eu também manteria pelo menos 2 semanas no master antes de fazer um RC. Agora na prática talvez seja assim mesmo..

Pessoalmente, terei que voltar ao dask / outras coisas após esse push no datetimearray. Eu esperava que pudéssemos ter um RC enquanto faço isso.

Existem outros problemas importantes que eu poderia identificar enquanto estamos passando por esta rodada de análises? Minha placa atualmente tem

• #24024 (em revisão)
• https://github.com/pandas-dev/pandas/pull/24227 (feito, em revisão)
• https://github.com/pandas-dev/pandas/pull/23581 (bloqueado por #24227)
• #23617 (bloqueado por #23581)
• E alguns problemas de documentos pendentes em torno do DatetimeAray.

sim, acho que devemos mesclar as coisas (que o tom mencionou) e sentar no mestre por uma semana ou 2 pelo menos

Para ser claro, também quero ver isso lançado o mais rápido possível, mas também precisamos ser realistas (por exemplo, não acho que teremos um lançamento final antes do final do ano, como você mencionou no fastparquet? todos os PRs de bloqueio são mesclados em uma semana que parece muito rápida IMO)

Se tivermos um período de RC mais longo e ainda fizermos uma limpeza adicional depois de fazer o RC (e possivelmente fazer um segundo RC), estou bem em fazer um RC rápido após a fusão.
Mas se virmos um RC como "pronto para ser lançado de nossa parte, se nenhum problema importante for relatado por pessoas que experimentam o RC, podemos fazer um lançamento final a partir disso", então devemos ter essas grandes mudanças no master para um pouco IMO.

Acho que tenho permissão para fazer um lançamento do fastparquet. Há uma mudança compatível para trás / para frente que pode ser lançada hoje.

Mas se virmos um RC como "pronto para ser lançado de nossa parte, se nenhum problema importante for relatado por pessoas que experimentam o RC, podemos fazer um lançamento final a partir disso", então devemos ter essas grandes mudanças no master para um pouco IMO.

Se tivermos um período de RC mais longo e ainda fizermos uma limpeza adicional depois de fazer o RC (e possivelmente fazer um segundo RC), estou bem em fazer um RC rápido após a fusão.

É basicamente onde estou. Assumindo que pendentes grandes PRs são mescladas esta semana (apenas assumindo, não um prazo real), então nós irá transformar-se problemas com eles nas próximas duas semanas. Minha esperança é que, fazendo um RC (ou dois), tenhamos mais chances de apresentar mais problemas, para que possamos fazer uma versão final de maior qualidade mais cedo.

O principal custo de fazer o RC mais cedo é que não temos mais fluência no escopo, o que pode ser uma coisa boa :)

Dito isso, não acho que fazer um RC a qualquer momento, digamos, nos dias 20 e 27 seja uma boa ideia por causa dos feriados. Então eu também estou bem em fazer um logo após o Ano Novo.

isso tudo soa bem; RC primeiro do ano;

@jreback @TomAugspurger @jorisvandenbossche
Você aceitaria um PR para #22724 antes do corte? Eu sei que você quer evitar o aumento de escopo e tirar isso da porta em breve, mas estou vindo do lado da consistência das coisas, onde essa é uma mudança que acho que poderia ser benéfica para ter mais cedo ou mais tarde. Pensei em perguntar antes de investir o tempo.

Falando nisso - você já tem uma ideia de qual será a política para quebrar as mudanças entre a v0.24 e a v0.25? Eles serão bloqueados completamente ou o master será movido para 1.0.0.dev imediatamente, com a v0.25 usando backports?

@jreback @TomAugspurger @jorisvandenbossche

Falando nisso - você já tem uma ideia de qual será a política para quebrar as mudanças entre a v0.24 e a v0.25? Eles serão bloqueados completamente ou o master será movido para 1.0.0.dev imediatamente, com a v0.25 usando backports?

Voltando a perguntar isso, já que - caso a quebra de PRs seja bloqueada até que a v.0.25 seja lançada - eu suspenderia todo o trabalho de quebra de PRs.

limpando os decks, por favor, não marque 0.24.0, a menos que seja uma mesclagem imediata. excluindo as limpezas que ainda estão sendo feitas por @jbrockmendel e @TomAugspurger

idealmente poderia fazer rc1 dizer na próxima semana, @TomAugspurger ?

Eu estava pensando na próxima semana também. Passando pelo backlog agora.

Em sex, 4 de janeiro de 2019 às 08:00 Jeff Reback [email protected] escreveu:

limpando os decks, por favor, não marque 0.24.0, a menos que seja uma mesclagem imediata.
excluindo as limpezas que ainda estão sendo feitas por @jbrockmendel
https://github.com/jbrockmendel e @TomAugspurger
https://github.com/TomAugspurger

idealmente poderia fazer rc1 dizer na próxima semana, @TomAugspurger
https://github.com/TomAugspurger ?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-451450878 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABQHIt1WfzSQoOTnbRYdwYdvo6Qo1Zy5ks5u_16OgaJpZM4Y9wcW
.

sim eu tambem

Voltando a perguntar isso, já que - caso a quebra de PRs seja bloqueada até que a v.0.25 seja lançada - eu suspenderia todo o trabalho de quebra de PRs.

Minha preferência é que as únicas alterações de quebra de API de 0,25 -> 1,0 sejam a remoção de recursos anteriormente obsoletos. Então os usuários podem

1. Certifique-se de que as coisas funcionem sem problemas no 0.25.x
2. Corrija quaisquer FutureWarnings de pandas
3. Atualize com confiança para 1.0

IIRC houve um acordo vago para isso na última reunião de desenvolvimento.

@TomAugspurger, o que significa que ainda fazemos alterações / reprovações no ciclo de desenvolvimento 0,25? (como essa foi a pergunta real de @h-vetinari, acho, além de 0,25 -> 1,0)

Eu realmente não me lembro do que dissemos sobre isso, apenas uma vaga lembrança do sprint no verão que já queríamos todas as reprovações em 0,24 e não adicionar mais em 0,25 (embora o resumo em https://github.com/pandas- dev/pandas/wiki/Pandas-Sprint- (julho de 2018) fala apenas sobre ter todas as reprovações em 0.25 e removê-las em 1.0).

Desculpe se interpretei errado. Sua vaga lembrança corresponde à minha vaga lembrança sobre depreciações para 0.25.0 :)

Queremos rever essa política? IOW queremos permitir novas descontinuações na versão 0.25.0 que sejam

• Removido em 1.0 (sem muito tempo para a comunidade se adaptar)
• Mantido para 1.0 e removido em 2.0 (se estivermos fazendo semver)

devemos ter uma chamada sobre o plano depois que 0,24 estiver fora da porta

Eu gostaria de cortar o RC1 em ~ 4 horas, depois que https://github.com/pandas-dev/pandas/pull/24708 for mesclado. Alguma objeção?

Precisamos discutir o quão conservadores somos com a fusão de PRs durante o período de RC. Não me lembro do que fizemos da última vez (apenas PRs que estão corrigindo bugs com o RC especificamente? Ou coisas "pequenas" estão OK?).

ok o RC, sim pequenas coisas estão ok. Se tivermos grande , talvez precisemos de RC2

Marcando agora e passando pelos testes locais antes de enviar a tag. Ping-me se você encontrar um bloqueador de última hora.

@TomAugspurger você mencionou que iria escrever uma postagem no blog para o lançamento, mas suponho que apenas para o lançamento final?
Nesse caso, pode ser bom já ter alguns destaques (comecei a rascunhar alguns); o arquivo whatsnew pode usar alguma limpeza em geral.

Alguma ideia de quanto tempo vai demorar? Eu estava prestes a empurrar a tag :)

No entanto, posso reconstruir os documentos que serão enviados para o servidor da Web a partir de um commit diferente.

Você tem um pouco mais de tempo, pois acho que preciso fazer algum trabalho em nossa receita de conda-forge para garantir numpy >= 1.12 :)

Sim, não espere por mim. Tenho outro trabalho para terminar primeiro.

OK. marcado.

Em sex, 11 de janeiro de 2019 às 09:13 Joris Van den Bossche <
[email protected]> escreveu:

Sim, não espere por mim. Tenho outro trabalho para terminar primeiro.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453548795 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABQHIsamTvr2YaLm68tQDFCX40_nraSTks5vCKo3gaJpZM4Y9wcW
.

Comecei a mexer no arquivo whatsnew para extrair os destaques, e já pensei em:

• Refatoração do tratamento interno de tipos de dados personalizados:
  
  
  
  • Melhor integração da interface ExtensionArray
  
  
  • Period e Interval agora podem ser armazenados em colunas Series/DataFrame (antes apenas em Index)
  
  
• Novo atributo .array em Series e Index para acessar os valores subjacentes e o método to_numpy para converter em matrizes numpy.
• Número inteiro opcional NA
• mudanças esparsas

Existe algum destaque a ser mencionado para toda a refatoração do tipo datetime? (além de "refatorar o tratamento interno de tipos de dados personalizados")

Quaisquer outros novos recursos ou alterações que vale a pena mencionar?

https://github.com/pandas-dev/pandas/releases/tag/v0.24.0rc1 tem alguns.

Em sex, 11 de janeiro de 2019 às 09:51 Joris Van den Bossche <
[email protected]> escreveu:

Comecei a examinar o arquivo whatsnew para extrair destaques e
já pensou em:

• Refatoração do tratamento interno de tipos de dados personalizados:
  
  
  
  • Melhor integração da interface ExtensionArray
  
  
  • Período e intervalo agora podem ser armazenados em Série/DataFrame
    
    colunas (antes apenas no Índice)
  
  
• Novo atributo .array em Series e Index para acessar o subjacente
  valores e o método to_numpy para converter em matrizes numpy.
• Número inteiro opcional NA
• mudanças esparsas

Existe algum destaque a ser mencionado para toda a refatoração do tipo datetime?
(além de "refatorar o tratamento interno de tipos de dados personalizados")

Quaisquer outros novos recursos ou alterações que vale a pena mencionar?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453561740 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABQHIh4Abyv5aEhn2vAA7KAJziTL75Rkks5vCLL7gaJpZM4Y9wcW
.

Os binários estão sendo construídos e os documentos HTML estão disponíveis em http://pandas.pydata.org.

Enviará um anúncio ainda hoje, assim que os binários estiverem prontos.

As rodas Mac e Linux estão no PyPI. Os pacotes de conda estão chegando ao conda-forge, e eu enviei o e-mail de anúncio.

https://github.com/pandas-dev/pandas-release tem algumas coisas que precisam ser corrigidas. Alguns são específicos para RC, então não estou muito preocupado com eles. Vou tentar resolver todos os problemas finais enquanto faço a versão final e, em seguida, espero que alguém possa experimentar as coisas, para ver quais coisas específicas da máquina eu codifiquei acidentalmente lá.

nenhuma roda do Windows para 0.24.0rc1?

Não tenho certeza se @cgohlke normalmente cria e carrega candidatos a lançamento.

Eu estou trabalhando nisso. A compilação pypy estava falhando ...

Obrigado @cgohlke , as rodas do Windows estão no PyPI agora.

Provavelmente devemos fazer 0.24.0 esta semana. Alguma objeção? Algum bloqueador?

Não sei se vou terminar https://github.com/pandas-dev/pandas/pull/24674 . Não terá muito tempo esta semana.

sem objeções - gostaria de obter o que está marcado atualmente para 0,24,0 em, mas se em alguns dias eles não forem, então ok para adiar

@TomAugspurger todos os problemas e PRs estão limpos para 0.24.0

Farei um documento rápido PR adicionando um rótulo de experimento a DatetimeArray e
TimedeltaArray, com um aviso de que .dtype deve mudar no
futuro.

Na quarta-feira, 23 de janeiro de 2019 às 7h03 Jeff Reback [email protected]
escreveu:

@TomAugspurger https://github.com/TomAugspurger todos os problemas e relações públicas são
limpar por 0,24,0

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Planejando a fusão

• DOC: Adicionar nota experimental a DatetimeArray e TimedeltaArray
  https://github.com/pandas-dev/pandas/pull/24882
• DOC: Sem limpeza em sphinx_build
  https://github.com/pandas-dev/pandas/pull/24902
• DOC: também redirecionar o antigo URL do whatsnew
  https://github.com/pandas-dev/pandas/pull/24906
• https://github.com/pandas-dev/pandas/pull/24905
• Reverta o uso de correção BUG-24212 de Index.take em pd.merge
  https://github.com/pandas-dev/pandas/pull/24904

e marque logo em seguida. Mais alguma coisa do RC?

Na quarta-feira, 23 de janeiro de 2019 às 7h15 Tom Augspurger [email protected]
escreveu:

Farei um documento rápido PR adicionando um rótulo de experimento a DatetimeArray e
TimedeltaArray, com um aviso de que .dtype deve mudar no
futuro.

Na quarta-feira, 23 de janeiro de 2019 às 7h03 Jeff Reback [email protected]
escreveu:

@TomAugspurger https://github.com/TomAugspurger todos os problemas e relações públicas são
limpar por 0,24,0

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Até

• https://github.com/pandas-dev/pandas/pull/24909
• https://github.com/pandas-dev/pandas/pull/24926

Se as pessoas tiverem pensamentos rápidos sobre #24926 (removendo IntervalArray do nível superior, apenas usando pd.arrays.IntervaArray ), então um +/-1 rápido ali seria útil.

@TomAugspurger Antes de marcar, você pode fazer uma última configuração da data nos documentos do whatsnew? (agora ainda XX de janeiro) Ou no commit de lançamento

Tudo mesclado eu acho!

Obrigado, marcando.

bom @TomAugspurger

Uau! Parabéns. Obrigado por todo o trabalho duro. Realmente ansioso para o lançamento.

sdist e binários estão no PyPI e conda-forge. O Anaconda está construindo para padrões agora.

Obrigado a todos.

E obrigado!