La idea es que 0.24.0 sea la última versión compatible con py2, ¿verdad?

24021 corrige el comportamiento de un caso de esquina en las comparaciones de marcas de tiempo, pero también introduce una inconsistencia entre el comportamiento de py2/py3. #21394 hizo el cambio análogo a las comparaciones Timedelta.

Lo _menos_ consistente que podríamos hacer es mantener el statu quo, cambiando el comportamiento de Timedelta pero no el comportamiento de Timestamp. La pregunta es si a) fusionar #24021 y tener un comportamiento py2/py3 no coincidente en 0.24.0, o b) revertir #21394 hasta después de 0.24.0 y esperar a cambiar ambos en la primera versión solo de py3.

Me inclino un poco por la opción b.

La idea es que 0.24.0 sea la última versión compatible con py2, ¿verdad?

Básicamente, aunque asumo que haremos un backporting y haremos un 0.24.1 o 2 que también sea compatible con py2.

No estoy muy familiarizado con esta sección, pero su opción b parece razonable.

Aunque... podría vivir con un comportamiento inconsistente de py2/py3. ¿Y seríamos consistentes con el edificio? Ese no sería el único.

pregunta: con
https://github.com/pandas-dev/pandas/pull/24021 ¿seríamos consistentes con el timedelta integrado de cada versión?

Este lanzamiento es realmente grande, pero v.0.24 también es bastante especial porque definirá efectivamente la API 1.0 (en el sentido de la política de no obsolescencia entre 0.24 y 1.0), y también por la magnitud de todo el esfuerzo de EA, obviamente. .

Pero, a pesar de mucho trabajo duro, el estado actual todavía se siente un poco a medias:

• El refactor de fecha y 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 , incluidos varios puntos relacionados con la funcionalidad principal como __setitem_ (#24020) o merge (#23020) o interacción entre EAs y otros objetos (pandas) (#22962 / #22974), groupby (#22861), etc.
• regresiones: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression
• pd.Array : #23581
• consistencia en los nuevos atributos (¿recomendando .array sobre .values todas partes?) #23995
• En aras de la coherencia (especialmente también en relación con los EA), creo que uno realmente debería limpiar la API alrededor de unique antes de 1.0 (#24108)
• varias otras cosas que estoy dejando de lado por brevedad

De manera realista, un lanzamiento antes de fin de año significaría un corte en ~ 10 días como máximo, lo que parece poco realista desde mi punto de vista, incluso si se toman atajos.

Dado que la siguiente declaración de @TomAugspurger arriba

Básicamente, aunque asumo que haremos un backporting y haremos un 0.24.1 o 2 que también sea compatible con py2.

efectivamente significa más soporte PY2 a principios de 2019 de todos modos, creo que uno debería considerar no intentar forzar el lanzamiento antes de fin de año.

Si hay un lanzamiento antes de fin de año (resp. antes de que se resuelvan los problemas más importantes), estoy especialmente de acuerdo con Tom en que tendrá que haber 0.24.1 para PY2, como 0.24.0 tendrá demasiados problemas (que con suerte aparecerán en el RC, pero bueno...) para ser el último lanzamiento, en mi opinión.

Alternativamente (que está más en línea con https://python3statement.org/, pero también es más controvertido), uno podría considerar tener un último 0.23.5 compatible con PY2 este año, y luego hacer 0.24.0 como solo PY3. el próximo año...?

@h-vetinari pandas es un proyecto de voluntariado casi en su totalidad. Por lo tanto, las prioridades del proyecto se establecen por consenso de la comunidad y se trabaja para alcanzarlas. Tenemos lanzamientos regulares en el tiempo; 0.24.0 en realidad está atrasado por unos meses. Tratar de agregar cosas adicionales que en sí mismas necesitan discusión no va a suceder.

Todo lo que existe en la serie 0.24.x es el último lanzamiento de Python 2, esto se ha anunciado hace mucho tiempo. Así es como es.

No sigo el punto de
https://github.com/pandas-dev/pandas/issues/24060#issuecomment -444777018. ¿Podría intentar reformularlo/resumirlo?

Creo que Py2 vs Py3 es irrelevante para 0.24.0.

Creo que todos los problemas relacionados con EA que vinculaste están en 0.24 (no los revisé todos). Ese es básicamente el bloqueador en este punto, pero no he revisado la acumulación recientemente.

No he tenido tiempo de mirar en único.

@jreback

@h-vetinari pandas es un proyecto de voluntariado casi en su totalidad. Por lo tanto, las prioridades del proyecto se establecen por consenso de la comunidad y se trabaja para alcanzarlas. Tenemos lanzamientos regulares en el tiempo; 0.24.0 en realidad está atrasado por unos meses. Tratar de agregar cosas adicionales que en sí mismas necesitan discusión no va a suceder.

Sé todo eso. Solo digo que retrasarse es una mala razón para apresurar un lanzamiento, si algunos de los cambios principales aún no se han desarrollado por completo (hablando principalmente de regresiones EA +).

Todo lo que existe en la serie 0.24.x es el último lanzamiento de Python 2, esto se ha anunciado hace mucho tiempo. Así es como es.

No sé de qué se ha hablado en otros canales, pero lo que vi en GH fue que la decisión principal fue 0.24->0.25->1.0 . Re:PY2, también se ha dicho (y hay una advertencia al respecto en Whatsnew) que no habrá lanzamientos de PY2 después del 31 de diciembre de 2018. La compatibilidad con la serie 0.24.0 para PY2 es otro ~6-8 mes de respaldar PY2 (ya que, de lo contrario, sería muy engorroso respaldar a la rama 0.24). Por supuesto que es una opción válida, pero solo quería sugerir la posibilidad de dejar PY2 en el muy estable 0.23.5.

@TomAugspurger

No sigo el punto de

24060 (comentario). ¿Podría intentar reformularlo/resumirlo?

Creo que Py2 vs Py3 es irrelevante para 0.24.0.

Lo siento, esto no estaba claro. Los dos puntos principales (interrelacionados) son:

• uno no debe apresurarse 0.24 debido a la fecha límite establecida (para apoyar PY2) del 31 de diciembre.
  
  
  
  • enumeró algunos problemas para eso: algunos de estos (y muchos más relacionados que no etiqueté) se han enviado a "Contribuciones bienvenidas" en lugar de v.0.24
  
  
  • mencioné que 0.24 es especial debido a la política de bloqueo de API hasta 1.0, y que creo que sería una lástima para .unique (pero entiendo que soy una voz solitaria en el desierto sobre eso una)
  
  
• señale la discrepancia entre el cuadro de advertencia ("A partir del 1 de enero de 2019, los lanzamientos de características de pandas solo admitirán Python 3") y la compatibilidad con la serie 0.24 para PY2, junto con la sugerencia de tener un 0.23.5 para PY2

Creo que todos los problemas relacionados con EA que vinculaste están en 0.24 (no los revisé todos). Ese es básicamente el bloqueador en este punto, pero no he revisado la acumulación recientemente.

La acumulación se ha reducido sustancialmente recientemente, sobre todo por los problemas que se enviaron a "Contribuciones bienvenidas" (también para problemas de EA). Esto va hacia mi punto de tomar atajos para sacar esto pronto.

Habiendo dicho eso, soy bastante nuevo en este juego, y no dudo que los desarrolladores principales tengan el panorama general a la vista y bajo control, pero señalar una observación no hace daño, espero.

No he tenido tiempo de mirar en único.

Bastante justo, el tiempo de desarrollo es un recurso muy limitado. Supongo que tendré que tratar de convencer a todos de esto en la tierra post-1.0. ;-)

@h-vetinari

Sé todo eso. Solo digo que retrasarse es una mala razón para apresurar un lanzamiento, si algunos de los cambios principales aún no se han desarrollado por completo (hablando principalmente de regresiones EA +).

Si seguimos agregando y agregando, entonces el lanzamiento seguirá retrasándose para siempre. He dibujado una línea en la arena. Así es como sacas el producto por la puerta. Una vez que el DTA aterrice por completo, estaremos en condiciones de liberarlo. Así que esto no está tan lejos. Claro que podríamos hacer un trabajo extra y simplemente decir que 0.23.5 es la última versión de PY2 (y, por supuesto, publicarla). Pero va a ser más fácil volver a una rama estable, lo que significa la serie 0.24.x.

Siempre hay cosas que agregar en un lanzamiento, pero este ya es el más grande que hemos tenido. Hay errores inevitables y es mejor hacerlo más temprano que tarde. Gracias por tus contribuciones. No es posible obtener todos los cambios importantes de API aquí. Tiene toda la razón en que el tiempo de desarrollo es un recurso realmente limitado.

@jreback
Gracias por la respuesta. Entiendo que quieres publicar esto lo antes posible, lo cual es bastante justo, por supuesto.

Pero va a ser más fácil volver a una rama estable, lo que significa la serie 0.24.x.

Parece que no entendí bien que los pandas dejarían de admitir PY2 el 1 de enero de 2019... Tal vez debería adaptar ese cuadro de advertencia en las noticias (" v.0.24.x será la última serie compatible con PY2; comenzando con v.0.25.0 , los pandas serán solo para python3"...?)

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

HACER
Agregue todas las advertencias de depreciación (supongo que habrá bastantes). Esto debe incluirse en lo siguiente:

• Aritmética de ticks de día con otros Ticks, Timedeltas y DatetimeTZ
• DatetimeIndex.shift (solo tz-aware)

Migración
El plan es que _Day (anteriormente CalendarDay) simplemente reemplace a Day una vez que se reemplace el comportamiento de Day anterior.

Preocupación
Durante el último chat de desarrollo, hubo interés en que 'D' fuera un argumento/compensación de frecuencia compatible con Timedelta y Datetime. No veo una manera clara de hacer esto posible sin agregar muchos parches de mono.

Ejemplo: timedelta_range(..., freq='D'); to_offset('D') devolverá _Day en el futuro y este desplazamiento deberá incrementar un Timedelta, pero _Day + Timedelta no es una operación válida.

¿Alguien tiene opiniones sobre el problema de consistencia de la marca de tiempo/timedelta py2/py3?

Un montón de obsolescencias se enumeran como Para ser eliminado en 1.0; ¿Debería 0.25.0 tomar el lugar de 1.0 para algunos de ellos?

¿Alguien tiene opiniones sobre el problema de consistencia de la marca de tiempo/timedelta py2/py3?

¿Puedes resumir ese problema? Idealmente, solo seguiríamos a python (cualquiera que sea la versión que se esté ejecutando) aquí, creo. Pero creo que no entiendo completamente el problema.

Un montón de obsolescencias se enumeran como Para ser eliminado en 1.0; ¿Debería 0.25.0 tomar el lugar de 1.0 para algunos de ellos?

Creo que todos ellos... Sin embargo, necesito discutir eso, algunos pueden necesitar ser presionados.

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

Timedelta se cambió recientemente para que devuelva NotInplemented en caso de que haya surgido anteriormente. Como resultado, su comportamiento de py2 coincide con python pero difiere del comportamiento de pandas py3.

Timestamp tiene un PR abierto para realizar el cambio análogo.

Una vez que se elimina py2, el cambio es definitivamente correcto. Hasta entonces, hay argumentos de consistencia contradictorios.

Deberíamos obtener el PR de marca de tiempo para 0.24.0 o revertir el PR de Timedelta hasta después de 0.24.0

(Escribiendo con los pulgares; LMk si no está claro)

creo que vamos a revertir el Timedelta, luego empujarlos a ambos por 0.25/1.0 (solo py3)

Moviendo este comentario https://github.com/pandas-dev/pandas/pull/24227#issuecomment -446680041 aquí:

(para lo cual, en mi opinión, también necesitaremos al menos un par de semanas en el maestro)

[Tom] Solo para verificar, deberíamos hacer una versión candidata con DatetimeArray lo antes posible, ¿verdad? ¿Y luego 1-2 semanas en el maestro mientras el RC está fuera?

Personalmente, no, no haría eso (si te refieres a ASAP como unos días después). También lo mantendría al menos 2 semanas en master antes de hacer un RC. Ahora, en la práctica, tal vez sea así de todos modos.

Personalmente, tendré que volver a dask / otras cosas después de este impulso en datetimearray. Esperaba que pudiéramos tener un RC mientras hago eso.

¿Hay otros problemas importantes que podría detectar mientras realizamos esta ronda de revisiones? Mi placa actualmente tiene

• #24024 (en revisión)
• https://github.com/pandas-dev/pandas/pull/24227 (hecho, en revisión)
• https://github.com/pandas-dev/pandas/pull/23581 (bloqueado por #24227)
• #23617 (bloqueado por #23581)
• Y un par de problemas de documentación pendientes sobre DatetimeAray.

sí, creo que deberíamos fusionar cosas (que tom mencionó) y luego sentarnos en el maestro durante una semana o 2 al menos

Para ser claros, también quiero ver este lanzamiento lo antes posible, pero también debemos ser realistas (p. ej., no creo que tengamos un lanzamiento final antes de fin de año, como mencionaste en fastparquet, incluso si todos los PR de bloqueo se fusionan en una semana que parece demasiado rápido en mi opinión)

Si tenemos un período de RC más largo, y aún hacemos más limpieza después de hacer el RC (y posiblemente hagamos un segundo RC), estoy de acuerdo con hacer un RC rápido después de la fusión.
Pero si vemos un RC como "listo para ser lanzado de nuestra parte, si las personas que prueban el RC no informan ningún problema importante, podemos hacer un lanzamiento final a partir de eso", entonces deberíamos tener esos cambios importantes en el maestro para un poco en mi opinión.

Creo que tengo los permisos para hacer un lanzamiento rápido de parquet. Hay un cambio compatible con versiones anteriores y posteriores que podría lanzarse hoy.

Pero si vemos un RC como "listo para ser lanzado de nuestra parte, si las personas que prueban el RC no informan ningún problema importante, podemos hacer un lanzamiento final a partir de eso", entonces deberíamos tener esos cambios importantes en el maestro para un poco en mi opinión.

Si tenemos un período de RC más largo, y aún hacemos más limpieza después de hacer el RC (y posiblemente hagamos un segundo RC), estoy de acuerdo con hacer un RC rápido después de la fusión.

Eso es básicamente donde estoy. Suponiendo que las grandes RP pendientes se fusionaron esta semana (asumiendo simplemente, no una fecha límite real), entonces vamos a subir problemas con ellos en el próximo par de semanas. Mi esperanza es que al hacer un RC (o dos) es más probable que encontremos más problemas, para que podamos hacer un lanzamiento final de mayor calidad antes.

El costo principal de hacer el RC antes es que no obtenemos más alcance lento, lo que puede ser algo bueno :)

Dicho esto, no creo que hacer un RC en ningún momento, digamos, del 20 al 27 sea una buena idea debido a las vacaciones. Así que también estoy bien con hacer uno poco después del Año Nuevo.

que todo suena bien; RC primero del año;

@jreback @TomAugspurger @jorisvandenbossche
¿Aceptaría un PR para #22724 antes del corte? Sé que desea evitar el avance del alcance y sacar esto pronto, pero vengo del lado de la consistencia de las cosas, donde este es un cambio que creo que podría ser beneficioso tener más temprano que tarde. Pensé en preguntar antes de invertir el tiempo.

Hablando de eso, ¿ya tiene una idea de cuál será la política para interrumpir los cambios entre v0.24 y v0.25? ¿Se bloquearán por completo o se moverá el maestro a 1.0.0.dev inmediatamente, con v0.25 usando backports?

@jreback @TomAugspurger @jorisvandenbossche

Hablando de eso, ¿ya tiene una idea de cuál será la política para interrumpir los cambios entre v0.24 y v0.25? ¿Se bloquearán por completo o se moverá el maestro a 1.0.0.dev inmediatamente, con v0.25 usando backports?

Volviendo a preguntar esto, ya que, en caso de que se bloquee la ruptura de relaciones públicas hasta que se publique la v.0.25, suspendería todo el trabajo para romper las relaciones públicas.

limpiando las cubiertas, por favor no marque para 0.24.0 a menos que una fusión inmediata. excluyendo las limpiezas que aún están haciendo @jbrockmendel y @TomAugspurger

Idealmente, ¿podría decir rc1 la próxima semana, @TomAugspurger ?

Yo también estaba pensando en la próxima semana. Pasando por la cartera de pedidos en este momento.

El viernes 4 de enero de 2019 a las 8:00 a. m. Jeff Reback [email protected] escribió:

limpiando las cubiertas, por favor no marque para 0.24.0 a menos que una fusión inmediata.
excluyendo las limpiezas que aún realiza @jbrockmendel
https://github.com/jbrockmendel y @TomAugspurger
https://github.com/TomAugspurger

idealmente podría hacer rc1 decir la próxima semana, @TomAugspurger
https://github.com/TomAugspurger ?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-451450878 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABQHIt1WfzSQoOTnbRYdwYdvo6Qo1Zy5ks5u_16OgaJpZM4Y9wcW
.

Sí, yo tambien

Volviendo a preguntar esto, ya que, en caso de que se bloquee la ruptura de relaciones públicas hasta que se publique la v.0.25, suspendería todo el trabajo para romper las relaciones públicas.

Mi preferencia es que los únicos cambios que rompen la API de 0.25 -> 1.0 son la eliminación de funciones obsoletas anteriormente. Entonces los usuarios pueden

1. Asegúrese de que todo funcione sin problemas en 0.25.x
2. Corrija cualquier advertencia futura de pandas
3. Actualice con confianza a 1.0

IIRC hubo un acuerdo general sobre esto en la última reunión de desarrollo.

@TomAugspurger significa que todavía hacemos cambios importantes/desaprobaciones en el ciclo de desarrollo 0.25. (ya que esa era la pregunta real de @ h-vetinari, creo, además de 0.25 -> 1.0)

Realmente no recuerdo lo que dijimos al respecto, solo un vago recuerdo del sprint en verano de que ya queríamos todas las obsolescencias en 0.24 y no agregar más en 0.25 (aunque el resumen en https://github.com/pandas- dev/pandas/wiki/Pandas-Sprint- (julio de 2018) solo habla de tener todas las obsolescencias en 0.25 y eliminarlas en 1.0).

Lo siento si leí mal. Su vago recuerdo coincide con mi vago recuerdo sobre las depreciaciones para 0.25.0 :)

¿Queremos revisar esa política? IOW, ¿queremos permitir nuevas obsolescencias en 0.25.0 que sean

• Eliminado en 1.0 (sin mucho tiempo para que la comunidad se adapte)
• Mantenido para 1.0 y eliminado en 2.0 (si estamos haciendo semver)

deberíamos tener una llamada sobre el plan después de que 0.24 salga por la puerta

Me gustaría cortar RC1 en ~ 4 horas, después de fusionar https://github.com/pandas-dev/pandas/pull/24708 . ¿Alguna objeción?

Tendremos que discutir qué tan conservadores somos con la fusión de los RP durante el período RC. No recuerdo lo que hicimos la última vez (¿solo los relaciones públicas que corrigen errores con el RC específicamente? ¿O las cosas "pequeñas" están bien?).

ok, el RC, sí, las cosas pequeñas están bien. Si tenemos grandes , tal vez necesitemos RC2

Etiquetar ahora y pasar por las pruebas locales antes de enviar la etiqueta. Hazme un ping si encuentras un bloqueador de última hora.

@TomAugspurger mencionó que iba a escribir una publicación de blog para el lanzamiento, pero supongo que solo para el lanzamiento final.
En ese caso, podría ser bueno tener ya algunos aspectos destacados (comencé a redactar algunos); el archivo whatsnew puede usar algo de limpieza en general.

¿Alguna idea de cuánto tiempo tomará? Estaba a punto de empujar la etiqueta :)

Sin embargo, puedo reconstruir los documentos que se enviarán al servidor web desde una confirmación diferente.

Tienes un poco más de tiempo, ya que creo que necesito trabajar un poco en nuestra receta de conda-forge para asegurar numpy> = 1.12 :)

Sí, no me esperes. Tengo otro trabajo que terminar primero.

está bien. etiquetado

El viernes, 11 de enero de 2019 a las 9:13 a.m. Joris Van den Bossche <
[email protected]> escribió:

Sí, no me esperes. Tengo otro trabajo que terminar primero.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453548795 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABQHIsamTvr2YaLm68tQDFCX40_nraSTks5vCKo3gaJpZM4Y9wcW
.

Empecé a revisar el archivo whatsnew para extraer los aspectos más destacados y ya pensé en:

• Refactorización del manejo interno de tipos de datos personalizados:
  
  
  
  • Mejor integración de la interfaz ExtensionArray
  
  
  • El período y el intervalo ahora se pueden almacenar en las columnas Serie / Marco de datos (antes solo en el Índice)
  
  
• Nuevo atributo .array en Serie e Índice para acceder a los valores subyacentes, y método to_numpy para convertir a matrices numpy.
• Entero opcional NA
• cambios escasos

¿Hay algún punto destacado que mencionar para toda la refactorización similar a la fecha y hora? (aparte de "refactorizar el manejo interno de tipos de datos personalizados")

¿Alguna otra característica nueva o cambio que valga la pena mencionar?

https://github.com/pandas-dev/pandas/releases/tag/v0.24.0rc1 tiene algunos.

El viernes, 11 de enero de 2019 a las 9:51 a. m. Joris Van den Bossche <
[email protected]> escribió:

Empecé a revisar el archivo whatsnew para extraer los aspectos más destacados y
ya pensé en:

• Refactorización del manejo interno de tipos de datos personalizados:
  
  
  
  • Mejor integración de la interfaz ExtensionArray
  
  
  • El período y el intervalo ahora se pueden almacenar en Series / DataFrame
    
    columnas (antes solo en Index)
  
  
• Nuevo atributo .array en Serie e Índice para acceder al subyacente
  valores y el método to_numpy para convertir a matrices numpy.
• Entero opcional NA
• cambios escasos

¿Hay algún punto destacado que mencionar para toda la refactorización similar a la fecha y hora?
(aparte de "refactorizar el manejo interno de tipos de datos personalizados")

¿Alguna otra característica nueva o cambio que valga la pena mencionar?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453561740 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABQHIh4Abyv5aEhn2vAA7KAJziTL75Rkks5vCLL7gaJpZM4Y9wcW
.

Los archivos binarios se están construyendo y los documentos HTML están disponibles en http://pandas.pydata.org.

Enviaremos un anuncio más tarde hoy, una vez que los binarios estén listos.

Las ruedas de Mac y Linux están en PyPI. Los paquetes de Conda están llegando a conda-forge y envié el correo electrónico de anuncio.

https://github.com/pandas-dev/pandas-release tiene algunas cosas que necesitan arreglarse. Algunos son específicos de RC, por lo que no estoy demasiado preocupado por ellos. Intentaré solucionar todos los problemas finales mientras hago el lanzamiento final, y luego espero que alguien más pueda probar las cosas, para ver qué cosas específicas de la máquina he codificado accidentalmente allí.

no hay rueda de windows para 0.24.0rc1?

No estoy seguro de si @cgohlke suele

Estoy en ello. La compilación pypy estaba fallando...

Gracias @cgohlke , las ruedas de Windows están en PyPI ahora.

Probablemente deberíamos hacer 0.24.0 esta semana. ¿Alguna objeción? ¿Algún bloqueador?

No sé si terminaré https://github.com/pandas-dev/pandas/pull/24674 . No tendré mucho tiempo esta semana.

sin objeciones: me gusta obtener lo que está marcado actualmente para 0.24.0 en pero si en un par de días no es así, está bien posponerlo

@TomAugspurger todos los problemas y relaciones públicas están limpios para 0.24.0

Haré un documento PR rápido agregando una etiqueta de experimento a DatetimeArray y
TimedeltaArray, con una advertencia de que se espera que .dtype cambie en el
futuro.

El miércoles 23 de enero de 2019 a las 7:03 a. m. Jeff Reback [email protected]
escribió:

@TomAugspurger https://github.com/TomAugspurger todos los problemas y relaciones públicas son
limpio para 0.24.0

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Planeando fusionarse

• DOC: agregue una nota experimental a DatetimeArray y TimedeltaArray
  https://github.com/pandas-dev/pandas/pull/24882
• DOC: No limpiar en sphinx_build
  https://github.com/pandas-dev/pandas/pull/24902
• DOC: también redirigir la antigua url de whatsnew
  https://github.com/pandas-dev/pandas/pull/24906
• https://github.com/pandas-dev/pandas/pull/24905
• Revertir BUG-24212 corrige el uso de Index.take en pd.merge
  https://github.com/pandas-dev/pandas/pull/24904

y etiquetar poco después. ¿Algo más del RC?

El miércoles 23 de enero de 2019 a las 7:15 a. m. Tom Augspurger
escribió:

Haré un documento PR rápido agregando una etiqueta de experimento a DatetimeArray y
TimedeltaArray, con una advertencia de que se espera que .dtype cambie en el
futuro.

El miércoles 23 de enero de 2019 a las 7:03 a. m. Jeff Reback [email protected]
escribió:

@TomAugspurger https://github.com/TomAugspurger todos los problemas y relaciones públicas son
limpio para 0.24.0

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Abajo a

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

Si las personas tienen pensamientos rápidos sobre #24926 (eliminando IntervalArray del nivel superior, simplemente usando pd.arrays.IntervaArray ), entonces sería útil un rápido +/-1 allí.

@TomAugspurger Antes de etiquetar, ¿puede hacer una última configuración de la fecha en los documentos de whatsnew? (ahora todavía enero XX) O en el compromiso de lanzamiento

Todo fusionado creo!

Gracias, etiquetando.

bueno @TomAugspurger

¡Guau! Felicidades. Gracias por todo el trabajo duro. Realmente espero con ansias el lanzamiento.

sdist y binarios están disponibles en PyPI y conda-forge. Anaconda está construyendo para los valores predeterminados ahora.

Gracias a todos.

¡Y gracias!