L'idée est que 0.24.0 soit la dernière version prenant en charge py2, n'est-ce pas ?

24021 corrige un comportement de cas critique dans les comparaisons d'horodatage, mais introduit également une incohérence entre le comportement py2/py3. #21394 a apporté le changement analogue aux comparaisons Timedelta.

La chose la moins cohérente que nous puissions faire est de maintenir le statu quo, en modifiant le comportement Timedelta mais pas le comportement Timestamp. La question est de savoir s'il faut a) fusionner #24021 et avoir un comportement py2/py3 incompatible dans 0.24.0, ou b) revenir #21394 jusqu'après 0.24.0 et attendre de changer les deux dans la première version py3 uniquement.

Je penche légèrement vers l'option b.

L'idée est que 0.24.0 soit la dernière version prenant en charge py2, n'est-ce pas ?

Fondamentalement, bien que je suppose que nous allons faire du rétroportage et faire un 0.24.1 ou 2 qui prend également en charge py2.

Je ne connais pas très bien cette section, mais votre option b semble raisonnable.

Bien que... je pourrais vivre avec un comportement py2 / py3 incohérent. Et serions-nous cohérents avec le bâtiment ? Ce ne serait pas le seul.

Question : avec
https://github.com/pandas-dev/pandas/pull/24021 serions-nous cohérents avec le timedelta intégré de chaque version ?

Cette version est en effet grosse, mais la v.0.24 est également assez spéciale car elle définira efficacement l'API 1.0 (au sens de la politique de non-dépréciation entre 0.24 et 1.0), et aussi à cause de l'ampleur de l'effort global d'EA évidemment .

Mais - malgré beaucoup de travail acharné - l'état actuel semble encore un peu à moitié cuit :

• Le refactor Datetime : 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 , y compris plusieurs points touchant les fonctionnalités de base comme __setitem_ (#24020) ou merge (#23020) ou interaction entre EAs et d'autres objets (pandas) (#22962 / #22974), groupby (#22861) etc.
• régressions : https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression
• pd.Array : #23581
• cohérence dans les nouveaux attributs (recommander .array sur .values partout ?) #23995
• Par souci de cohérence (en particulier en ce qui concerne les EA également), je pense qu'il faut vraiment nettoyer l'API autour de unique avant 1.0 (#24108)
• plusieurs autres choses que je laisse de côté par souci de brièveté

De manière réaliste, une sortie avant la fin de l'année signifierait une coupure dans environ 10 jours maximum, ce qui semble irréaliste d'après mon POV, même si je coupe les coins ronds.

Étant donné que la déclaration suivante de @TomAugspurger ci-dessus

Fondamentalement, bien que je suppose que nous allons faire du rétroportage et faire un 0.24.1 ou 2 qui prend également en charge py2.

signifie effectivement plus de support PY2 au début de 2019 de toute façon, je pense que l'on devrait envisager de ne pas essayer de forcer la sortie avant la fin de l'année.

S'il y a une sortie avant la fin de l'année (resp. avant que les problèmes les plus importants ne soient résolus), alors je suis particulièrement d'accord avec Tom qu'il devra y avoir un 0.24.1 pour PY2, comme 0.24.0 aura trop de problèmes (qui, espérons-le, font surface dans la RC, mais bon...) pour être la dernière version, IMO.

Alternativement (ce qui est simultanément plus conforme à https://python3statement.org/, mais aussi plus controversé), on pourrait envisager d'avoir un dernier 0.23.5 prenant en charge PY2 cette année, puis de faire 0.24.0 en tant que PY3 uniquement L'année prochaine...?

@h-vetinari pandas est un projet de volontariat presque entièrement. Ainsi, les priorités du projet sont fixées par consensus communautaire et mises en œuvre. Nous avons des sorties régulières dans le temps ; 0.24.0 est en fait en retard de quelques mois. Essayer d'ajouter des éléments

Tout ce qui existe dans la série 0.24.x est la dernière version de Python 2, cela a été annoncé depuis longtemps. C'est juste comme ça.

Je ne suis pas le point de
https://github.com/pandas-dev/pandas/issues/24060#issuecomment -444777018. Pourriez-vous essayer de le reformuler/le résumer ?

Je pense que Py2 contre Py3 n'est pas pertinent pour 0.24.0.

Les problèmes liés à EA que vous avez liés sont, je pense, tous en 0,24 (je ne les ai pas tous vérifiés). C'est essentiellement le bloqueur à ce stade, mais je n'ai pas examiné l'arriéré récemment.

Je n'ai pas eu le temps de me pencher sur l'unique.

@jreback

@h-vetinari pandas est un projet de volontariat presque entièrement. Ainsi, les priorités du projet sont fixées par consensus communautaire et mises en œuvre. Nous avons des sorties régulières dans le temps ; 0.24.0 est en fait en retard de quelques mois. Essayer d'ajouter des éléments supplémentaires qui eux-mêmes nécessitent une discussion ne se produira pas.

Je sais tout ça. Je dis juste qu'être en retard est une mauvaise raison de précipiter une sortie, si certains des changements de base n'ont pas encore été complètement développés (en parlant principalement d'EA + régressions).

Tout ce qui existe dans la série 0.24.x est la dernière version de Python 2, cela a été annoncé depuis longtemps. C'est juste comme ça.

Je ne sais pas ce qui a été discuté sur les autres chaînes, mais ce que j'ai vu sur GH, c'est que la décision principale était 0.24->0.25->1.0 . Re: PY2, il a également été dit (et il y a un avertissement à cet effet sur les news) qu'il n'y aura pas de versions PY2 après le 31 décembre 2018. La prise en charge de la série 0.24.0 pour PY2 est un autre ~ 6-8 mois de prendre en charge PY2 (car le rétroportage vers 0,24 branche serait autrement très fastidieux). Bien sûr, c'est un choix valable, mais je voulais juste suggérer la possibilité de laisser PY2 au très stable 0,23,5 à la place.

@TomAugspurger

Je ne suis pas le point de

24060 (commentaire). Pourriez-vous essayer de le reformuler/le résumer ?

Je pense que Py2 contre Py3 n'est pas pertinent pour 0.24.0.

Désolé ce n'était pas clair. Les deux points principaux (interreliés) sont :

• il ne faut pas se précipiter 0,24 en raison de la date limite indiquée (pour soutenir PY2) du 31 décembre.
  
  
  
  • énuméré quelques problèmes pour cela - certains d'entre eux (et beaucoup d'autres liés que je n'ai pas marqués) ont été poussés vers "Contributions Welcome" au lieu de v.0.24
  
  
  • a soulevé que 0.24 est spécial en raison de la politique de verrouillage API jusqu'à 1.0, et que je pense que ce serait dommage pour .unique (mais je comprends que je suis une seule voix dans le désert à ce sujet un)
  
  
• signaler l'écart entre la boîte d'avertissement ("À partir du 1er janvier 2019, les versions de fonctionnalités pandas prendront en charge Python 3 uniquement") et la prise en charge de la série 0.24 pour PY2, ainsi que la suggestion d'avoir un 0.23.5 pour PY2

Les problèmes liés à EA que vous avez liés sont, je pense, tous en 0,24 (je ne les ai pas tous vérifiés). C'est essentiellement le bloqueur à ce stade, mais je n'ai pas examiné l'arriéré récemment.

L'arriéré a été considérablement réduit récemment, notamment par le fait que les problèmes ont été poussés vers « Contributions bienvenues » (également pour les problèmes d'EA). Cela va vers mon point de couper les coins ronds pour sortir cela bientôt.

Cela étant dit, je suis assez nouveau dans ce jeu, et je ne doute pas que les développeurs principaux aient une vue d'ensemble et sous contrôle - mais souligner une observation ne peut pas faire de mal, j'espère.

Je n'ai pas eu le temps de me pencher sur l'unique.

Assez juste, le temps de développement est une ressource très limitée. Je suppose que je vais devoir essayer de convaincre tout le monde de cela dans les pays post-1.0. ;-)

@h-vetinari

Je sais tout ça. Je dis juste qu'être en retard est une mauvaise raison de précipiter une sortie, si certains des changements de base n'ont pas encore été complètement développés (en parlant principalement d'EA + régressions).

Si nous continuons d'ajouter et d'ajouter, alors la sortie ne cesse d'être retardée pour toujours. J'ai tracé une ligne dans le sable. C'est ainsi que vous obtenez le produit à la porte. Une fois que le DTA atterrira complètement, nous serons en mesure de le libérer. Ce n'est donc pas si loin. Bien sûr, nous pourrions faire un travail supplémentaire et dire simplement que 0.23.5 est la dernière version de PY2 (et bien sûr la publier). Mais il sera plus facile de revenir à une branche stable, ce qui signifie la série 0.24.x.

Il y a toujours des choses à ajouter dans une version, mais celle-ci est déjà la plus importante que nous ayons jamais eue. Il y a des bugs inévitables et il vaut donc mieux le faire le plus tôt possible. Merci pour vos contributions. Il n'est pas possible d'obtenir toutes les modifications majeures de l'API ici. Vous avez parfaitement raison, le temps de développement est une ressource vraiment limitée.

@jreback
Merci pour la réponse. Je comprends que vous vouliez sortir cela dès que possible, ce qui est assez juste, bien sûr.

Mais il sera plus facile de revenir à une branche stable, ce qui signifie la série 0.24.x.

Il semble que je mal compris que les pandas géants cesseraient soutenir AP2 par 1 janvier 2019 ... Peut - être devrait adapter cette boîte d'avertissement dans les whatsnews alors ( » v.0.24.x sera la dernière série qui supports AP2, en commençant par v.0.25.0 , les pandas seront uniquement en python3"...?)

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

FAIRE
Ajoutez tous les avertissements de dépréciation (je prévois qu'il y en ait pas mal). Cela doit être inclus dans les éléments suivants :

• Arithmétique des ticks du jour avec d'autres ticks, Timedeltas et DatetimeTZ
• DatetimeIndex.shift (compatible tz uniquement)

Migration
Le plan est que _Day (anciennement CalendarDay) remplace simplement Day une fois que le comportement Day précédent est remplacé.

Préoccuper
Lors du dernier chat de développement, il y avait un intérêt pour que « D » soit un argument/décalage de fréquence compatible avec Timedelta et Datetime. Je ne vois pas de moyen clair de rendre cela possible sans ajouter beaucoup de patchs de singe.

Exemple : timedelta_range(..., freq='D'); to_offset('D') renverra _Day dans le futur et ce décalage devra incrémenter un Timedelta, mais _Day + Timedelta est une opération invalide.

Quelqu'un a-t-il des opinions sur le problème de cohérence d'horodatage/timedelta py2/py3 ?

Un tas de dépréciations sont répertoriés comme À supprimer dans la version 1.0 ; 0.25.0 devrait-il remplacer 1.0 pour certains d'entre eux ?

Quelqu'un a-t-il des opinions sur le problème de cohérence d'horodatage/timedelta py2/py3 ?

Pouvez-vous résumer ce problème? Idéalement, nous suivrions simplement python (quelle que soit la version en cours d'exécution) ici, je pense. Mais je ne pense pas avoir bien compris le problème.

Un tas de dépréciations sont répertoriés comme À supprimer dans la version 1.0 ; 0.25.0 devrait-il remplacer 1.0 pour certains d'entre eux ?

Je pense que tous... Besoin d'en discuter cependant, certains peuvent avoir besoin d'être poussés.

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

Timedelta a récemment été modifié pour renvoyer NotInplemented au cas où il aurait été soulevé précédemment. En conséquence, son comportement py2 correspond à python mais diffère du comportement py3 de pandas.

Timestamp a un PR ouvert pour effectuer le changement analogue.

Une fois que py2 est supprimé, le changement est définitivement correct. Jusque-là, il existe des arguments de cohérence contradictoires.

Nous devrions soit obtenir le Timestamp PR pour 0,24.0, soit rétablir le Timedelta PR jusqu'après 0,24.0

(Saisie avec les pouces ; LMk si pas clair)

je pense que nous allons revenir sur celui de Timedelta, puis les pousser tous les deux pour 0.25/1.0 (py3 uniquement)

Déplacer ce commentaire https://github.com/pandas-dev/pandas/pull/24227#issuecomment -446680041 ici :

(pour laquelle IMO nous aurons également besoin d'au moins quelques semaines en master)

[Tom] Juste pour vérifier, nous devrions faire une release candidate avec DatetimeArray dès que possible, n'est-ce pas ? Et puis 1-2 semaines sur master pendant que la RC est sortie ?

Personnellement, non, je ne ferais pas ça (si vous voulez dire avec ASAP comme quelques jours après). Je voudrais aussi le garder au moins 2 semaines en master avant de faire un RC. Maintenant dans la pratique ce sera peut-être comme ça de toute façon..

Personnellement, je devrai revenir à dask / autres choses après cette poussée sur datetimearray. J'espérais que nous pourrions avoir un RC pendant que je fais ça.

Y a-t-il d'autres problèmes majeurs que je pourrais relever pendant que nous procédons à cette série d'examens ? Mon assiette a actuellement

• #24024 (en révision)
• https://github.com/pandas-dev/pandas/pull/24227 (fait, en révision)
• https://github.com/pandas-dev/pandas/pull/23581 (bloqué par #24227)
• #23617 (bloqué par #23581)
• Et quelques problèmes de documentation en suspens autour de DatetimeAray.

ouais je pense que nous devrions fusionner les choses (ce que Tom a mentionné) puis rester assis en maître pendant une semaine ou 2 au moins

Pour être clair, je veux aussi que cela sorte le plus tôt possible, mais nous devons aussi être réalistes (par exemple, je ne pense pas que nous aurons une version finale avant la fin de l'année comme vous l'avez mentionné sur fastparquet? même si tous les PR bloquants sont fusionnés en une semaine qui semble trop rapide IMO)

Si nous avons une période de RC plus longue et que nous effectuons encore un nettoyage supplémentaire après avoir effectué le RC (et éventuellement un deuxième RC), cela me convient de faire un RC rapide après la fusion.
Mais si nous considérons une RC comme « prête à être libérée de notre part, si aucun problème majeur n'est signalé par les personnes qui essaient la RC, nous pouvons en faire une version finale », alors nous devrions avoir ces changements majeurs dans le maître pour un peu OMI.

Je pense avoir les permissions pour faire une version fastparquet. Il y a un changement de compatibilité ascendante / descendante qui pourrait être publié aujourd'hui.

Mais si nous considérons une RC comme « prête à être libérée de notre part, si aucun problème majeur n'est signalé par les personnes qui essaient la RC, nous pouvons en faire une version finale », alors nous devrions avoir ces changements majeurs dans le maître pour un peu OMI.

Si nous avons une période de RC plus longue et que nous effectuons encore un nettoyage supplémentaire après avoir effectué le RC (et éventuellement un deuxième RC), cela me convient de faire un RC rapide après la fusion.

Voilà en gros où j'en suis. En supposant que les grandes sont fusionnées en cours PRs cette semaine ( en supposant que, pas une date limite réelle), alors nous tournerons des problèmes avec eux dans les deux prochaines semaines. J'espère qu'en faisant une RC (ou deux), nous aurons plus de chances de trouver plus de problèmes, afin que nous puissions faire une version finale de meilleure qualité plus tôt.

Le coût principal de faire le RC plus tôt est que nous n'obtenons plus de fluage de portée, ce qui peut être une bonne chose :)

Cela dit, je ne pense pas que faire un RC à tout moment, disons, du 20 au 27 est une bonne idée à cause des vacances. Donc, je suis également d'accord pour en faire un peu de temps après le nouvel an.

que tout sonne bien ; RC premier de l'année;

@jreback @TomAugspurger @jorisvandenbossche
Accepteriez-vous un PR pour #22724 avant la date limite ? Je sais que vous voulez éviter le fluage de la portée et sortir cela de la porte bientôt, mais je viens du côté de la cohérence des choses, où c'est un changement que je pense qu'il pourrait être bénéfique d'avoir le plus tôt possible. Je pensais demander avant d'investir du temps.

En parlant de cela, avez-vous déjà une idée de la politique de rupture des modifications entre la v0.24 et la v0.25 ? Seront-ils complètement bloqués ou passeront-ils immédiatement à 1.0.0.dev, avec la v0.25 utilisant des rétroportages ?

@jreback @TomAugspurger @jorisvandenbossche

En parlant de cela, avez-vous déjà une idée de la politique de rupture des modifications entre la v0.24 et la v0.25 ? Seront-ils complètement bloqués ou passeront-ils immédiatement à 1.0.0.dev, avec la v0.25 utilisant des rétroportages ?

Re-demander cela, car - au cas où les PR cassés seraient bloqués jusqu'à la sortie de la v.0.25 - je suspendrais tout travail sur les PR cassés.

en effaçant les ponts, les pls ne marquent pas pour 0.24.0 à moins d'une fusion immédiate. à l'exclusion des nettoyages encore effectués par @jbrockmendel et @TomAugspurger

idéalement pourrait faire rc1 dire la semaine prochaine, @TomAugspurger ?

Je pensais aussi à la semaine prochaine. Passer par l'arriéré en ce moment.

Le vendredi 4 janvier 2019 à 8h00, Jeff Reback [email protected] a écrit :

en effaçant les ponts, les pls ne marquent pas pour 0.24.0 à moins d'une fusion immédiate.
à l'exclusion des nettoyages encore effectués par @jbrockmendel
https://github.com/jbrockmendel et @TomAugspurger
https://github.com/TomAugspurger

idéalement pourrait faire rc1 dire la semaine prochaine, @TomAugspurger
https://github.com/TomAugspurger ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-451450878 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABQHIt1WfzSQoOTnbRYdwYdvo6Qo1Zy5ks5u_16OgaJpZM4Y9wcW
.

ouais moi aussi

Re-demander cela, car - au cas où les PR cassés seraient bloqués jusqu'à la sortie de la v.0.25 - je suspendrais tout travail sur les PR cassés.

Ma préférence est que les seuls changements qui brisent l'API de 0.25 -> 1.0 soient la suppression des fonctionnalités précédemment obsolètes. Ensuite, les utilisateurs peuvent

1. Assurez-vous que les choses se passent bien sur 0.25.x
2. Corrigez tous les FutureWarnings des pandas
3. Passez à la version 1.0 en toute confiance

IIRC, il y avait un accord vague à ce sujet lors de la dernière réunion de développement.

@TomAugspurger, ce

Je ne me souviens pas vraiment de ce que nous avons dit à ce sujet, seulement un vague souvenir du sprint de l'été que nous voulions déjà toutes les dépréciations en 0.24 et ne pas en rajouter en 0.25 (bien que le résumé dans https://github.com/pandas- dev/pandas/wiki/Pandas-Sprint- (juillet-2018) ne parle que d'avoir toutes les dépréciations en 0.25 et de les supprimer en 1.0).

Désolé si j'ai mal lu. Votre vague souvenir correspond à mon vague souvenir sur les dépréciations pour 0.25.0 :)

Voulons-nous revoir cette politique? IOW voulons-nous autoriser de nouvelles dépréciations dans 0.25.0 qui sont soit

• Supprimé en 1.0 (sans beaucoup de temps pour que la communauté s'adapte)
• Maintenu pour 1.0, et supprimé en 2.0 (si nous faisons semver)

nous devrions avoir un appel sur le plan après que 0,24 soit sorti

J'aimerais couper RC1 dans environ 4 heures, après la fusion de https://github.com/pandas-dev/pandas/pull/24708 . Des objections?

Nous devrons discuter à quel point nous sommes prudents avec la fusion des PR pendant la période de RC. Je ne me souviens pas de ce que nous avons fait la dernière fois (seuls les PR qui corrigent des bogues avec le RC en particulier ? Ou les "petites" choses sont OK ?).

ok le RC, ouais les petites choses sont ok. Si nous avons grand alors peut-être besoin de RC2

Tagging maintenant, et passer par les tests locaux avant de pousser le tag. Envoyez-moi un ping si vous trouvez un bloqueur de dernière minute.

@TomAugspurger, vous avez mentionné que vous alliez écrire un article de blog pour la sortie, mais je suppose que pour la sortie finale ?
Dans ce cas, il serait peut-être bon d'avoir déjà quelques faits saillants (j'ai commencé à en rédiger) ; le fichier whatsnew peut utiliser un peu de nettoyage en général.

Une idée du temps que ça va prendre ? J'étais sur le point de pousser le tag :)

Cependant, je peux reconstruire les documents qui seront poussés vers le serveur Web à partir d'un commit différent.

Vous avez un peu plus de temps, car je pense que je dois travailler sur notre recette conda-forge pour assurer numpy >= 1.12 :)

Ouais, ne m'attends pas. J'ai d'autres travaux à terminer d'abord.

D'ACCORD. tagué.

Le ven. 11 janv. 2019 à 09:13 Joris Van den Bossche <
[email protected]> a écrit :

Ouais, ne m'attends pas. J'ai d'autres travaux à terminer d'abord.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453548795 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABQHIsamTvr2YaLm68tQDFCX40_nraSTks5vCKo3gaJpZM4Y9wcW
.

J'ai commencé à parcourir le fichier whatsnew pour extraire les faits saillants, et j'ai déjà pensé à :

• Refactorisation de la gestion interne des types de données personnalisés :
  
  
  
  • Meilleure intégration de l'interface ExtensionArray
  
  
  • La période et l'intervalle peuvent désormais être stockés dans les colonnes Series / DataFrame (avant uniquement dans l'index)
  
  
• Nouvel attribut .array sur Series et Index pour accéder aux valeurs sous-jacentes, et méthode to_numpy pour convertir en tableaux numpy.
• Entier optionnel NA
• changements épars

Y a-t-il un point culminant à mentionner pour toute la refactorisation de type datetime ? (hormis le "refactor du traitement interne des types de données personnalisés")

Y a-t-il d'autres nouvelles fonctionnalités ou changements à mentionner ?

https://github.com/pandas-dev/pandas/releases/tag/v0.24.0rc1 en a quelques-uns.

Le ven. 11 janv. 2019 à 09:51 Joris Van den Bossche <
[email protected]> a écrit :

J'ai commencé à parcourir le fichier Whatsnew pour extraire les faits saillants, et
déjà pensé à :

• Refactorisation de la gestion interne des types de données personnalisés :
  
  
  
  • Meilleure intégration de l'interface ExtensionArray
  
  
  • La période et l'intervalle peuvent maintenant être stockés dans Series / DataFrame
    
    colonnes (avant seulement dans Index)
  
  
• Nouvel attribut .array sur Series et Index pour accéder au sous-jacent
  valeurs et la méthode to_numpy pour convertir en tableaux numpy.
• Entier optionnel NA
• changements épars

Y a-t-il un point culminant à mentionner pour toute la refactorisation de type datetime ?
(hormis le "refactor du traitement interne des types de données personnalisés")

Y a-t-il d'autres nouvelles fonctionnalités ou changements à mentionner ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453561740 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABQHIh4Abyv5aEhn2vAA7KAJziTL75Rkks5vCLL7gaJpZM4Y9wcW
.

Les binaires sont en construction et les documents HTML sont disponibles sur http://pandas.pydata.org.

Enverra une annonce plus tard dans la journée, une fois les binaires terminés.

Les roues Mac et Linux sont sur PyPI. Les paquets Conda affluent dans conda-forge, et j'ai envoyé l'e-mail d'annonce.

https://github.com/pandas-dev/pandas-release a quelques points à corriger. Certains sont spécifiques à la RC, donc je ne suis pas trop inquiet à leur sujet. J'essaierai de résoudre tous les derniers problèmes lors de la publication de la version finale, puis j'espère que quelqu'un d'autre pourra essayer des choses, pour voir quels éléments spécifiques à la machine j'ai accidentellement encodés là-dedans.

pas de roue windows pour 0.24.0rc1 ?

Je ne sais pas si @cgohlke crée et télécharge généralement des candidats à la publication.

Je suis dessus. La compilation pypy échouait...

Merci @cgohlke , les roues Windows sont maintenant sur PyPI.

Nous devrions probablement faire 0.24.0 cette semaine. Des objections? Des bloqueurs ?

Je ne sais pas si je ferai https://github.com/pandas-dev/pandas/pull/24674 . Je n'aurai pas trop de temps cette semaine.

pas d'objections - j'aime obtenir ce qui est marqué actuellement pour 0,24,0 mais si dans quelques jours ils ne sont pas alors ok pour différer

@TomAugspurger tous les problèmes et relations publiques sont propres pour 0.24.0

Je vais faire un rapide doc PR en ajoutant une étiquette d'expérience à DatetimeArray et
TimedeltaArray, avec un avertissement indiquant que .dtype devrait changer dans le
futur.

Le mercredi 23 janvier 2019 à 7 h 03 Jeff Reback [email protected]
a écrit:

@TomAugspurger https://github.com/TomAugspurger tous les problèmes et relations publiques sont
nettoyer pour 0.24.0

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Projet de fusion

• DOC : ajouter une note expérimentale à DatetimeArray et TimedeltaArray
  https://github.com/pandas-dev/pandas/pull/24882
• DOC : Pas de nettoyage dans sphinx_build
  https://github.com/pandas-dev/pandas/pull/24902
• DOC : rediriger également l'ancienne URL Whatsnew
  https://github.com/pandas-dev/pandas/pull/24906
• https://github.com/pandas-dev/pandas/pull/24905
• Rétablir l'utilisation du correctif BUG-24212 d'Index.take dans pd.merge
  https://github.com/pandas-dev/pandas/pull/24904

et tag peu de temps après. Autre chose de la RC ?

Le mercredi 23 janvier 2019 à 7h15 Tom Augspurger [email protected]
a écrit:

Je vais faire un rapide doc PR en ajoutant une étiquette d'expérience à DatetimeArray et
TimedeltaArray, avec un avertissement indiquant que .dtype devrait changer dans le
futur.

Le mercredi 23 janvier 2019 à 7 h 03 Jeff Reback [email protected]
a écrit:

@TomAugspurger https://github.com/TomAugspurger tous les problèmes et relations publiques sont
nettoyer pour 0.24.0

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Jusqu'à

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

Si les gens ont des idées rapides sur #24926 (en supprimant IntervalArray du niveau supérieur, en utilisant simplement pd.arrays.IntervaArray ) alors un rapide +/-1 là-bas serait utile.

@TomAugspurger Avant de marquer, pouvez-vous effectuer un dernier réglage de la date dans les documents Whatsnew ? (maintenant toujours le XX janvier) Ou dans le commit de sortie

Tout fusionné je pense !

Merci, tagué.

sympa @TomAugspurger

Waouh ! Toutes nos félicitations. Merci pour tout le travail acharné. J'ai vraiment hâte de la sortie.

sdist et les binaires sont sur PyPI et conda-forge. Anaconda construit pour les valeurs par défaut maintenant.

Merci tout le monde.

Et merci!