Die Idee ist, dass 0.24.0 die letzte py2-unterstützende Version ist, oder?

24021 behebt ein Eck-Case-Verhalten in Zeitstempelvergleichen, führt aber auch eine Inkonsistenz zwischen py2/py3-Verhalten ein. #21394 hat die analoge Änderung an Timedelta-Vergleichen vorgenommen.

Das _am wenigsten_ konsistente, was wir tun könnten, wäre, den Status quo beizubehalten und das Timedelta-Verhalten zu ändern, aber nicht das Timestamp-Verhalten. Die Frage ist, ob Sie a) #24021 zusammenführen und ein nicht übereinstimmendes py2/py3-Verhalten in 0.24.0 aufweisen oder b) #21394 bis nach 0.24.0 zurücksetzen und warten sollten, um beides in der ersten py3-only-Version zu ändern.

Ich tendiere leicht zu Option b.

Die Idee ist, dass 0.24.0 die letzte py2-unterstützende Version ist, oder?

Grundsätzlich gehe ich jedoch davon aus, dass wir eine Rückportierung durchführen und eine 0.24.1 oder 2 erstellen, die auch py2 unterstützt.

Ich bin mit diesem Abschnitt nicht sehr vertraut, aber Ihre Option b klingt vernünftig.

Obwohl... ich könnte mit inkonsistentem py2/py3-Verhalten leben. Und würden wir mit dem Gebäude übereinstimmen Das wäre nicht das einzige.

Frage: mit
https://github.com/pandas-dev/pandas/pull/24021 würden wir mit dem eingebauten Zeitdelta jeder Version übereinstimmen?

Dieses Release ist zwar groß, aber v.0.24 ist auch etwas ganz Besonderes, weil es die 1.0 API effektiv definieren wird (im Sinne der No-Deprecation-Policy zwischen 0.24 und 1.0), und auch wegen des Umfangs des gesamten EA-Aufwands offensichtlich .

Aber – trotz vieler harter Arbeit – fühlt sich der aktuelle Zustand noch etwas unausgegoren an:

• Der Datetime-Refactor: 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 , einschließlich mehrerer Punkte, die Kernfunktionen wie __setitem_ (#24020) berühren oder merge (#23020) oder Interaktion zwischen EAs und anderen (Panda-) Objekten (#22962 / #22974), groupby (#22861) usw.
• Regressionen: https://github.com/pandas-dev/pandas/issues?q=is%3Aopen+is%3Aissue+label%3ARegression
• pd.Array : #23581
• Konsistenz in neuen Attributen (empfohlen .array über .values überall?) #23995
• Aus Konsistenzgründen (insbesondere auch in Bezug auf EAs) denke ich, dass man die API wirklich um unique vor 1.0 (#24108) aufräumen sollte.
• einige andere Dinge lasse ich der Kürze halber aus

Realistischerweise würde eine Veröffentlichung vor Ende des Jahres einen Cut-Off in maximal ~10 Tagen bedeuten, was aus meiner Sicht unrealistisch erscheint, auch wenn es Abstriche macht.

Angesichts der folgenden Aussage von @TomAugspurger oben

Grundsätzlich gehe ich jedoch davon aus, dass wir eine Rückportierung durchführen und eine 0.24.1 oder 2 erstellen, die auch py2 unterstützt.

effektiv sowieso mehr PY2-Unterstützung zu Beginn des Jahres 2019 bedeutet, sollte man meiner Meinung nach nicht versuchen, die Veröffentlichung vor Jahresende zu erzwingen.

Wenn es vor Ende des Jahres eine Veröffentlichung gibt (bzw. bevor die wichtigsten Punkte geklärt sind), dann stimme ich Tom insbesondere zu, dass es für PY2 ein 0.24.1 muss, als 0.24.0 wird zu viele Probleme haben (die hoffentlich im RC auftauchen, aber gut...) um die letzte Veröffentlichung zu sein, IMO.

Alternativ (was gleichzeitig eher https://python3statement.org/ entspricht, aber auch umstrittener ist) könnte man in Betracht ziehen, einen letzten PY2 zu haben, der in diesem Jahr 0,23,5 unterstützt, und dann 0,24,0 als nur PY3 zu machen nächstes Jahr...?

@h-vetinari pandas ist fast vollständig ein Freiwilligenprojekt. Auf diese Weise werden Projektprioritäten im Konsens der Gemeinschaft festgelegt und darauf hingearbeitet. Wir haben regelmäßige Veröffentlichungen rechtzeitig; 0.24.0 ist eigentlich um einige Monate überfällig. Der Versuch, zusätzliche Dinge hinzuzufügen, die selbst diskutiert werden müssen, wird nicht passieren.

Was auch immer in der 0.24.x-Serie existiert, ist die letzte Version für Python 2, dies wurde schon lange angekündigt. So ist es eben.

Ich verfolge nicht den Punkt von
https://github.com/pandas-dev/pandas/issues/24060#issuecomment -444777018. Könnten Sie versuchen, es neu zu formulieren / zusammenzufassen?

Ich denke, Py2 vs. Py3 ist für 0.24.0 irrelevant.

Die EA-bezogenen Probleme, die Sie verlinkt haben, gehen meiner Meinung nach alle in 0.24 (ich habe sie nicht alle überprüft). Das ist im Grunde der Blocker an dieser Stelle, aber ich habe den Rückstand in letzter Zeit nicht überprüft.

Ich hatte keine Zeit, nach Unikaten zu suchen.

@jreback

@h-vetinari pandas ist fast vollständig ein Freiwilligenprojekt. Auf diese Weise werden Projektprioritäten im Konsens der Gemeinschaft festgelegt und darauf hingearbeitet. Wir haben regelmäßige Veröffentlichungen rechtzeitig; 0.24.0 ist eigentlich um einige Monate überfällig. Der Versuch, zusätzliche Dinge hinzuzufügen, die selbst diskutiert werden müssen, wird nicht passieren.

Ich weiß das alles. Ich sage nur, dass Überfälligkeit ein schlechter Grund ist, eine Veröffentlichung zu überstürzen, wenn einige der Kernänderungen noch nicht vollständig entwickelt sind (hauptsächlich über EA + Regressionen).

Was auch immer in der 0.24.x-Serie existiert, ist die letzte Version für Python 2, dies wurde schon lange angekündigt. So ist es eben.

Ich weiß nicht, was in anderen Kanälen diskutiert wurde, aber was ich auf GH gesehen habe, war, dass die Hauptentscheidung 0.24->0.25->1.0 . Betreff: PY2, es wurde auch gesagt (und es gibt eine entsprechende Warnung in den Neuigkeiten), dass es nach dem 31. Dezember 2018 keine Veröffentlichungen für das zweite Jahr geben wird. Die Unterstützung der 0,24.0-Serie für das zweite Jahr dauert weitere ~6-8 Monate PY2 zu unterstützen (da die Rückportierung auf 0,24-Zweig ansonsten sehr umständlich wäre). Natürlich ist das eine gültige Wahl, aber ich wollte nur die Möglichkeit vorschlagen, das PY2 stattdessen bei den sehr stabilen 0,23,5 zu belassen.

@TomAugspurger

Ich verfolge nicht den Punkt von

24060 (Kommentar). Könnten Sie versuchen, es neu zu formulieren / zusammenzufassen?

Ich denke, Py2 vs. Py3 ist für 0.24.0 irrelevant.

Das war leider nicht klar. Die wichtigsten (miteinander zusammenhängenden) zwei Punkte sind:

• man sollte 0,24 aufgrund der angegebenen Frist (für die Unterstützung von PY2) vom 31. Dezember nicht überstürzen.
  
  
  
  • habe dafür einige Probleme aufgelistet - einige davon (und viele weitere verwandte, die ich nicht markiert habe) wurden auf "Beiträge willkommen" anstatt auf v.0.24 verschoben
  
  
  • erwähnte, dass 0.24 aufgrund der API-Lock-Policy bis 1.0 etwas Besonderes ist und dass ich denke, dass dies für .unique schade wäre (aber ich verstehe, dass ich da eine einsame Stimme in der Wildnis bin eins)
  
  
• weisen Sie auf die Diskrepanz zwischen dem Warnfeld ("Ab dem 1. Januar 2019 werden Pandas-Feature-Releases werden nur Python 3 unterstützen") und der Unterstützung der 0.24-Serie für PY2 zusammen mit dem Vorschlag hin, eine 0.23.5 für PY2 zu haben

Die EA-bezogenen Probleme, die Sie verlinkt haben, gehen meiner Meinung nach alle in 0.24 (ich habe sie nicht alle überprüft). Das ist im Grunde der Blocker an dieser Stelle, aber ich habe den Rückstand in letzter Zeit nicht überprüft.

Der Rückstand wurde in letzter Zeit deutlich ausgedünnt, nicht zuletzt durch das Verschieben von Issues auf "Contributions Welcome" (auch für EA-Probleme). Dies geht in Richtung meines Punkts, Abstriche zu machen, um dies bald herauszubringen.

Davon abgesehen bin ich ziemlich neu in diesem Spiel und ich zweifle nicht daran, dass die Core-Entwickler das Gesamtbild im Blick und im Griff haben – aber auf eine Beobachtung hinzuweisen kann nicht schaden, hoffe ich.

Ich hatte keine Zeit, nach Unikaten zu suchen.

Fairerweise ist die Entwicklungszeit eine sehr begrenzte Ressource. Ich schätze, ich werde versuchen müssen, alle davon im Land nach 1.0 zu überzeugen. ;-)

@h-vetinari

Ich weiß das alles. Ich sage nur, dass Überfälligkeit ein schlechter Grund ist, eine Veröffentlichung zu überstürzen, wenn einige der Kernänderungen noch nicht vollständig entwickelt sind (hauptsächlich über EA + Regressionen).

Wenn wir ständig hinzufügen und hinzufügen, verzögert sich die Veröffentlichung für immer. Ich habe eine Linie in Sand gezeichnet. So bekommen Sie das Produkt aus der Tür. Sobald die DTA vollständig gelandet ist, werden wir in der Lage sein, sie freizugeben. Das ist also nicht mehr weit. Natürlich könnten wir zusätzliche Arbeit leisten und einfach sagen, dass 0.23.5 die letzte PY2-Version ist (und natürlich veröffentlichen). Aber es wird einfacher sein, zu einem stabilen Zweig zurückzukehren, was die 0.24.x-Serie bedeutet.

Es gibt immer Dinge, die in einer Veröffentlichung hinzugefügt werden müssen, aber diese ist bereits die größte, die wir je hatten. Es gibt unvermeidliche Fehler und daher besser früher als später. Danke für deine Beiträge. Es ist nicht möglich, hier jede größere API-Änderung zu erhalten. Sie haben genau recht, denn Entwicklungszeit ist eine wirklich begrenzte Ressource.

@jreback
Danke für die Antwort. Ich verstehe, dass Sie dies so schnell wie möglich aus der Tür bekommen möchten, was natürlich fair genug ist.

Aber es wird einfacher sein, zu einem stabilen Zweig zurückzukehren, was die 0.24.x-Serie bedeutet.

Scheinbar habe ich missverstanden, dass Pandas ab dem 1. Januar 2019 aufhören würden, PY2 zu unterstützen... Vielleicht sollte ich dann diese Warnbox in den Nachrichten anpassen (" v.0.24.x wird die letzte Serie sein, die PY2 unterstützt; beginnend mit v.0.25.0 , Pandas werden nur Python3 sein"...?)

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

MACHEN
Fügen Sie alle Abschreibungswarnungen hinzu (ich gehe davon aus, dass es einige davon gibt). Dies muss im Folgenden enthalten sein:

• Day-Tick-Arithmetik mit anderen Ticks, Timedeltas und DatetimeTZ
• DatetimeIndex.shift (nur tz-fähig)

Migration
Der Plan sieht vor, dass _Day (ehemals CalendarDay) nur Day ersetzt, sobald das Verhalten des vorherigen Days ersetzt wurde.

Anliegen
Während des letzten Dev-Chats bestand Interesse daran, dass 'D' mit dem Frequenzargument/-offset sowohl mit Timedelta als auch mit Datetime kompatibel ist. Ich sehe keinen klaren Weg, dies zu ermöglichen, ohne viel Monkeypatching hinzuzufügen.

Beispiel: timedelta_range(..., freq='D'); to_offset('D') gibt _Day in der Zukunft zurück und dieser Offset muss ein Timedelta erhöhen, aber _Day + Timedelta ist eine ungültige Operation.

Hat jemand Meinungen zum Zeitstempel-/Zeitdelta-py2/py3-Konsistenzproblem?

Eine Reihe von veralteten Versionen sind in 1.0 als zu entfernen aufgeführt; sollte 0,25,0 für einige von diesen 1,0 ersetzen?

Hat jemand Meinungen zum Zeitstempel-/Zeitdelta-py2/py3-Konsistenzproblem?

Können Sie das Problem zusammenfassen? Idealerweise würden wir hier einfach Python (welche Version auch immer läuft) folgen, denke ich. Aber ich glaube, ich verstehe das Problem nicht ganz.

Eine Reihe von veralteten Versionen sind in 1.0 als zu entfernen aufgeführt; sollte 0,25,0 für einige von diesen 1,0 ersetzen?

Ich denke, sie alle... Müssen das diskutieren, einige müssen vielleicht gedrängt werden.

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

Timedelta wurde kürzlich geändert, um NotInplemented zurückzugeben, falls es zuvor ausgelöst wurde. Als Ergebnis stimmt sein py2-Verhalten mit Python überein, unterscheidet sich jedoch vom py3-Verhalten von Pandas.

Timestamp hat einen offenen PR, um die analoge Änderung vorzunehmen.

Sobald py2 fallen gelassen wird, ist die Änderung definitiv richtig. Bis dahin gibt es widersprüchliche Konsistenzargumente.

Wir sollten entweder den Timestamp PR für 0.24.0 eingeben oder den Timedelta PR bis nach 0.24.0 . zurücksetzen

(Tippen mit Daumen; LMk wenn unklar)

Ich denke, lassen Sie uns das Timedelta zurücksetzen und dann beide für 0,25/1,0 (nur py3) hineinschieben.

Verschieben Sie diesen Kommentar https://github.com/pandas-dev/pandas/pull/24227#issuecomment -446680041 hier:

(wofür wir IMO auch mindestens ein paar Wochen im Master brauchen)

[Tom] Nur zur Überprüfung sollten wir so schnell wie möglich einen Release Candidate mit DatetimeArray erstellen, oder? Und dann 1-2 Wochen auf Master während der RC draußen ist?

Persönlich, nein, ich würde das nicht tun (wenn Sie so schnell wie möglich meinen, wie ein paar Tage später). Ich würde es auch mindestens 2 Wochen im Master behalten, bevor ich ein RC mache. In der Praxis wird es jetzt vielleicht sowieso so sein..

Persönlich muss ich nach diesem Push auf datetimearray zu Dask / anderen Dingen zurückkehren. Ich hatte gehofft, wir könnten einen RC haben, während ich das mache.

Gibt es andere wichtige Probleme, die ich aufgreifen könnte, während wir diese Überprüfungsrunde durchgehen? Mein Teller hat derzeit

• #24024 (in Überprüfung)
• https://github.com/pandas-dev/pandas/pull/24227 (fertig, im Rückblick)
• https://github.com/pandas-dev/pandas/pull/23581 (blockiert von #24227)
• #23617 (blockiert von #23581)
• Und ein paar ausstehende Dokumentationsprobleme rund um DatetimeAray.

Ja, ich denke, wir sollten Dinge zusammenführen (das hat Tom erwähnt) und dann mindestens eine oder zwei Wochen im Master sitzen

Um das klarzustellen, ich möchte auch, dass dies so schnell wie möglich veröffentlicht wird, aber wir müssen auch realistisch sein (zB glaube ich nicht, dass wir vor Ende des Jahres eine endgültige Veröffentlichung haben werden, wie Sie bei fastparquet erwähnt haben? selbst wenn alle blockierenden PRs werden in einer Woche zusammengeführt, die IMO zu schnell erscheint)

Wenn wir eine längere RC-Periode haben und nach der RC noch einige weitere Aufräumarbeiten durchführen (und möglicherweise eine zweite RC durchführen), kann ich nach dem Zusammenführen eine schnelle RC durchführen.
Aber wenn wir ein RC als "bereit sehen, von unserer Seite veröffentlicht zu werden, wenn keine größeren Probleme von Leuten gemeldet werden, die das RC ausprobieren, können wir daraus eine endgültige Veröffentlichung machen", dann sollten wir diese großen Änderungen in Master für a . haben bisschen IMO.

Ich glaube, ich habe die Berechtigung, eine Fastparquet-Freigabe durchzuführen. Es gibt eine abwärts-/vorwärtskompatible Änderung, die heute veröffentlicht werden könnte.

Aber wenn wir ein RC als "bereit sehen, von unserer Seite veröffentlicht zu werden, wenn keine größeren Probleme von Leuten gemeldet werden, die das RC ausprobieren, können wir daraus eine endgültige Veröffentlichung machen", dann sollten wir diese großen Änderungen in Master für a . haben bisschen IMO.

Wenn wir eine längere RC-Periode haben und nach der RC noch einige weitere Aufräumarbeiten durchführen (und möglicherweise eine zweite RC durchführen), kann ich nach dem Zusammenführen eine schnelle RC durchführen.

Da bin ich im Grunde. Unter der Annahme , dass herausragende große PRs in dieser Woche zusammengeführt wird (nur unter der Annahme, nicht eine tatsächliche Frist), dann werden wir wieder auftauchen Probleme mit ihnen in den nächsten paar Wochen. Ich hoffe, dass wir mit einem RC (oder zwei) mit größerer Wahrscheinlichkeit mehr Probleme aufdecken, sodass wir früher eine höherwertige endgültige Veröffentlichung veröffentlichen können.

Die Hauptkosten für die frühere Durchführung des RC sind, dass wir keinen Scope Creep mehr bekommen, was eine gute Sache sein kann :)

Das heißt, ich denke nicht, dass es eine gute Idee ist, zwischen dem 20. und 27. einen RC zu machen, wegen der Feiertage. Ich komme also auch gut damit zurecht, kurz nach Neujahr einen zu machen.

das hört sich alles gut an; RC erster des Jahres;

@jreback @TomAugspurger @jorisvandenbossche
Würden Sie eine PR für #22724 vor dem Cutoff akzeptieren? Ich weiß, dass Sie Scope Creep vermeiden und dies bald aus der Tür schaffen möchten, aber ich komme von der Konsistenzseite der Dinge, wo diese Änderung meiner Meinung nach eher früher als später von Vorteil sein könnte. Ich dachte, ich würde fragen, bevor ich die Zeit investiere.

Apropos – haben Sie bereits eine Vorstellung davon, wie die Richtlinien für Breaking Changes zwischen v0.24 und v0.25 sein werden? Werden sie komplett blockiert oder wird der Master sofort auf 1.0.0.dev umziehen, mit v0.25 unter Verwendung von Backports?

@jreback @TomAugspurger @jorisvandenbossche

Apropos – haben Sie bereits eine Vorstellung davon, wie die Richtlinien für Breaking Changes zwischen v0.24 und v0.25 sein werden? Werden sie komplett blockiert oder wird der Master sofort auf 1.0.0.dev umziehen, mit v0.25 unter Verwendung von Backports?

Ich stelle dies noch einmal, da - falls brechende PRs bis zur Veröffentlichung von v.0.25 blockiert würden - ich alle Arbeiten an brechenden PRs einstellen würde.

Wenn die Decks gelöscht werden, markieren Sie bitte nicht für 0.24.0, es sei denn, es erfolgt eine sofortige Zusammenführung. ausgenommen Aufräumarbeiten, die noch von @jbrockmendel und @TomAugspurger durchgeführt werden

im Idealfall könnte tun rc1 sagen nächste Woche, @TomAugspurger?

Ich dachte auch an nächste Woche. Gehe gerade den Rückstand durch.

Am Freitag, den 4. Januar 2019 um 8:00 Uhr schrieb Jeff Reback [email protected] :

Wenn die Decks gelöscht werden, markieren Sie bitte nicht für 0.24.0, es sei denn, es erfolgt eine sofortige Zusammenführung.
ausgenommen Aufräumarbeiten, die noch von @jbrockmendel durchgeführt werden
https://github.com/jbrockmendel und @TomAugspurger
https://github.com/TomAugspurger

idealerweise könnte rc1 nächste Woche sagen, @TomAugspurger
https://github.com/TomAugspurger ?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-451450878 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABQHIt1WfzSQoOTnbRYdwYdvo6Qo1Zy5ks5u_16OgaJpZM4Y9wcW
.

ja ich auch

Ich stelle dies noch einmal, da - falls brechende PRs bis zur Veröffentlichung von v.0.25 blockiert würden - ich alle Arbeiten an brechenden PRs einstellen würde.

Ich bevorzuge, dass die einzigen API-brechenden Änderungen von 0,25 -> 1,0 das Entfernen zuvor veralteter Funktionen sind. Dann können die Benutzer

1. Stellen Sie sicher, dass die Dinge auf 0.25.x . reibungslos laufen
2. Beheben Sie alle FutureWarnings von Pandas
3. Sicheres Upgrade auf 1.0

IIRC gab es beim letzten Entwicklertreffen eine lose Vereinbarung.

@TomAugspurger bedeutet, dass wir im 0,25-Entwicklungszyklus immer noch

Ich erinnere mich nicht wirklich, was wir dazu gesagt haben, nur eine vage Erinnerung an den Sprint im Sommer, dass wir bereits alle Deprecations in 0,24 und keine weiteren in 0,25 hinzufügen wollten (obwohl die Zusammenfassung in https://github.com/pandas- dev/pandas/wiki/Pandas-Sprint- (Juli-2018) spricht nur davon, alle Einstellungen in 0.25 zu haben und sie in 1.0 zu entfernen).

Sorry, wenn ich falsch gelesen habe. Deine vage Erinnerung stimmt mit meiner vagen Erinnerung an Abwertungen für 0.25.0 überein :)

Wollen wir diese Politik überdenken? IOW wollen wir neue Verwerfungen in 0.25.0 zulassen, die entweder

• In 1.0 entfernt (ohne viel Zeit für die Community, sich anzupassen)
• Gepflegt für 1.0 und entfernt in 2.0 (wenn wir Semver machen)

wir sollten einen Anruf nach dem Plan haben, nachdem 0,24 vor der Tür steht

Ich möchte RC1 in ~4 Stunden schneiden, nachdem https://github.com/pandas-dev/pandas/pull/24708 zusammengeführt wurde. Irgendwelche Einwände?

Wir müssen diskutieren, wie konservativ wir mit der Zusammenführung von PRs während der RC-Phase sind. Ich erinnere mich nicht, was wir letztes Mal gemacht haben (nur PRs, die speziell Fehler mit dem RC beheben? Oder "kleine" Dinge sind in Ordnung?).

ok der RC, ja kleine Dinge sind ok. Wenn wir groß haben, brauchen wir vielleicht RC2

Jetzt taggen und die lokalen Tests durchgehen, bevor das Tag übertragen wird. Ping mich an, wenn du einen Last-Minute-Blocker findest.

@TomAugspurger Sie haben erwähnt, dass Sie einen Blogbeitrag für die Veröffentlichung schreiben würden, aber ich nehme an, nur für die endgültige Veröffentlichung?
In diesem Fall könnte es gut sein, bereits einige Highlights zu haben (ich habe angefangen, einige zu entwerfen); die whatsnew-Datei kann im Allgemeinen einige Aufräumarbeiten gebrauchen.

Hast du eine Ahnung, wie lange es dauern wird? Ich war gerade dabei, das Etikett zu drücken :)

Ich kann jedoch die Dokumente neu erstellen, die von einem anderen Commit an den Webserver gepusht werden.

Du hast etwas mehr Zeit, da ich glaube, dass ich noch etwas an unserem Conda-Forge-Rezept arbeiten muss, um sicherzustellen, dass numpy >= 1.12 ist :)

Ja, warte nicht auf mich. Ich habe noch einige andere Arbeiten zu erledigen.

OK. markiert.

Am Fr, 11. Januar 2019 um 9:13 Uhr Joris Van den Bossche <
[email protected]> schrieb:

Ja, warte nicht auf mich. Ich habe noch einige andere Arbeiten zu erledigen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453548795 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABQHIsamTvr2YaLm68tQDFCX40_nraSTks5vCKo3gaJpZM4Y9wcW
.

Ich begann, die Whatsnew-Datei durchzugehen, um Highlights zu extrahieren, und dachte bereits an:

• Refactor des internen Umgangs mit benutzerdefinierten Datentypen:
  
  
  
  • Bessere Integration der ExtensionArray-Schnittstelle
  
  
  • Periode und Intervall können jetzt in Reihen / DataFrame-Spalten gespeichert werden (vorher nur in Index)
  
  
• Neues .array Attribut für Series und Index, um auf die zugrunde liegenden Werte zuzugreifen, und to_numpy Methode zum Konvertieren in numpy-Arrays.
• Optionale ganze Zahl NA
• spärliche Änderungen

Gibt es ein Highlight für all das Datetime-ähnliche Refactoring? (abgesehen von "Refactor des internen Umgangs mit benutzerdefinierten Datentypen")

Gibt es weitere erwähnenswerte Neuerungen oder Änderungen?

https://github.com/pandas-dev/pandas/releases/tag/v0.24.0rc1 hat ein paar.

Am Fr, 11. Januar 2019 um 9:51 Uhr Joris Van den Bossche <
[email protected]> schrieb:

Ich habe angefangen, die Whatsnew-Datei durchzugehen, um Highlights zu extrahieren, und
schon überlegt:

• Refactor des internen Umgangs mit benutzerdefinierten Datentypen:
  
  
  
  • Bessere Integration der ExtensionArray-Schnittstelle
  
  
  • Periode und Intervall können jetzt in Series / DataFrame gespeichert werden
    
    Spalten (vorher nur im Index)
  
  
• Neues .array-Attribut für Serien und Index für den Zugriff auf den Basiswert
  Werte und to_numpy-Methode zum Konvertieren in numpy-Arrays.
• Optionale ganze Zahl NA
• spärliche Änderungen

Gibt es ein Highlight für all das Datetime-ähnliche Refactoring?
(abgesehen von "Refactor des internen Umgangs mit benutzerdefinierten Datentypen")

Gibt es weitere erwähnenswerte Neuerungen oder Änderungen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453561740 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABQHIh4Abyv5aEhn2vAA7KAJziTL75Rkks5vCLL7gaJpZM4Y9wcW
.

Binärdateien werden erstellt und HTML-Dokumente sind unter http://pandas.pydata.org verfügbar.

Werde heute noch eine Ankündigung versenden, sobald die Binärdateien fertig sind.

Mac- und Linux-Räder sind auf PyPI. Conda-Pakete sickern in Conda-Forge ein, und ich habe die Ankündigungs-E-Mail verschickt.

https://github.com/pandas-dev/pandas-release enthält ein paar Dinge, die repariert werden müssen. Einige sind RC-spezifisch, daher mache ich mir keine Sorgen um sie. Ich werde versuchen, alle letzten Probleme auszubügeln, während ich die endgültige Veröffentlichung mache, und dann kann hoffentlich jemand anderes Dinge ausprobieren, um zu sehen, welche maschinenspezifischen Dinge ich versehentlich darin codiert habe.

kein Windows-Rad für 0.24.0rc1 ?

Ich bin mir nicht sicher, ob @cgohlke normalerweise Release-Kandidaten erstellt und hochlädt.

Ich bin dabei. Der pypy-Build schlug fehl...

Danke @cgohlke , Windows Wheels sind jetzt auf PyPI.

Wir sollten diese Woche wahrscheinlich 0.24.0 machen. Irgendwelche Einwände? Irgendwelche Blocker?

Ich weiß nicht, ob ich https://github.com/pandas-dev/pandas/pull/24674 fertig bekomme. Werde diese Woche nicht viel Zeit haben.

keine Einwände - möchte gerne das bekommen, was derzeit für 0,24,0 Zoll markiert ist, aber wenn sie in ein paar Tagen nicht mehr sind, dann ist es in Ordnung, aufzuschieben

@TomAugspurger alle Ausgaben und PRs sind sauber für 0.24.0

Ich mache eine kurze Doc-PR und füge DatetimeArray ein Experimentlabel hinzu und
TimedeltaArray, mit einer Warnung, dass sich .dtype voraussichtlich im
Zukunft.

Am Mittwoch, 23. Januar 2019 um 7:03 Uhr Jeff Reback [email protected]
schrieb:

@TomAugspurger https://github.com/TomAugspurger alle Ausgaben & PR's sind
sauber für 0.24.0

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Zusammenschluss planen

• DOC: Experimentelle Anmerkung zu DatetimeArray und TimedeltaArray hinzufügen
  https://github.com/pandas-dev/pandas/pull/24882
• DOC: Keine Bereinigung in sphinx_build
  https://github.com/pandas-dev/pandas/pull/24902
• DOC: auch alte Whatsnew-URL umleiten
  https://github.com/pandas-dev/pandas/pull/24906
• https://github.com/pandas-dev/pandas/pull/24905
• Setzen Sie BUG-24212-Fix-Verwendung von Index.take in pd.merge zurück
  https://github.com/pandas-dev/pandas/pull/24904

und kurz danach markieren. Sonst noch was vom RC?

Am Mi, 23. Januar 2019 um 7:15 Uhr Tom Augspurger [email protected]
schrieb:

Ich mache eine kurze Doc-PR und füge DatetimeArray ein Experimentlabel hinzu und
TimedeltaArray, mit einer Warnung, dass sich .dtype voraussichtlich im
Zukunft.

Am Mittwoch, 23. Januar 2019 um 7:03 Uhr Jeff Reback [email protected]
schrieb:

@TomAugspurger https://github.com/TomAugspurger alle Ausgaben & PR's sind
sauber für 0.24.0

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Bis zu

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

Wenn Leute schnell Gedanken zu #24926 haben (IntervalArray aus der obersten Ebene entfernen, einfach pd.arrays.IntervaArray ), dann wäre ein kurzes +/-1 dort nützlich.

@TomAugspurger Können Sie vor dem Taggen eine letzte Einstellung des Datums in den Whatsnew-Dokumenten vornehmen? (jetzt noch Januar XX) Oder im Release Commit

Alles zusammengeführt denke ich!

Danke, taggen.

nett @TomAugspurger

Wooo! Herzliche Glückwünsche. Vielen Dank für all die harte Arbeit. Freue mich schon sehr auf die Veröffentlichung.

sdist und Binärdateien sind auf PyPI und Conda-Forge verfügbar. Anaconda erstellt jetzt für Standardeinstellungen.

Danke an alle.

Und danke dir!