Pandas: РЛС: 0.24.0

Созданный на 3 дек. 2018  ·  61Комментарии  ·  Источник: pandas-dev/pandas

Проблема с отслеживанием

Открытые PR
Открытые вопросы

Давайте сократим. Я только что посмотрел последнюю версию Whatsnew, и она огромна. Давайте выясним это раньше, чем позже. Я знаю, что есть некоторые проблемы с блокировкой: DatetimeArray и что делать с CalendarDay.

Самый полезный комментарий

Я готов. Сборка pypy не удалась...

Все 61 Комментарий

Идея состоит в том, чтобы 0.24.0 была последней версией, поддерживающей py2, верно?

24021 исправляет поведение крайних случаев при сравнении меток времени, но также вносит несоответствие между поведением py2/py3. #21394 внесла аналогичные изменения в сравнения Timedelta.

_Наименее_ последовательная вещь, которую мы могли бы сделать, это сохранить статус-кво, изменив поведение Timedelta, но не поведение Timestamp. Вопрос заключается в том, следует ли а) объединить # 24021 и иметь несоответствующее поведение py2 / py3 в 0.24.0 или б) вернуть # 21394 до версии после 0.24.0 и подождать, чтобы изменить оба в первом выпуске только для py3.

Я немного склоняюсь к варианту б.

Идея состоит в том, чтобы 0.24.0 была последней версией, поддерживающей py2, верно?

В принципе, хотя я предполагаю, что мы сделаем бэкпорт и выпустим версию 0.24.1 или 2, которая также поддерживает py2.

Я не очень хорошо знаком с этим разделом, но ваш вариант b звучит разумно.

Хотя... я мог бы жить с непоследовательным поведением py2/py3. И будем ли мы соответствовать зданию, которое не будет единственным.

Вопрос: с
https://github.com/pandas-dev/pandas/pull/24021 будем ли мы соответствовать встроенной временной дельте каждой версии?

Этот выпуск действительно большой, но версия 0.24 также весьма особенная, потому что она будет эффективно определять API 1.0 (в смысле политики отсутствия устаревания между 0.24 и 1.0), а также из-за масштабов всех усилий EA, очевидно. .

Но, несмотря на большую тяжелую работу, текущее состояние все еще кажется немного недоработанным:

На самом деле выпуск до конца года будет означать отключение максимум через ~ 10 дней, что кажется нереальным с моей точки зрения, даже если срезать углы.

Учитывая, что следующее утверждение от @TomAugspurger выше

В принципе, хотя я предполагаю, что мы сделаем бэкпорт и выпустим версию 0.24.1 или 2, которая также поддерживает py2.

в любом случае фактически означает большую поддержку PY2 в начале 2019 года, я думаю, что следует подумать о том, чтобы не пытаться форсировать выпуск до конца года.

Если будет релиз до конца года (соответственно, до того, как будут решены самые важные проблемы), то я особенно согласен с Томом, что для PY2 потребуется 0.24.1 , так как 0.24.0 будет слишком много проблем (которые, надеюсь, всплывут в RC, но ладно...), чтобы стать последним релизом, IMO.

В качестве альтернативы (что одновременно больше соответствует https://python3statement.org/, но также и более противоречиво), можно рассмотреть возможность выпуска последней версии 0.23.5, поддерживающей PY2, в этом году, а затем сделать 0.24.0 только для PY3. Следующий год...?

@h-vetinari pandas — почти полностью волонтерский проект. Таким образом, приоритеты проекта устанавливаются на основе консенсуса сообщества и работают над их достижением. У нас есть регулярные релизы вовремя; 0.24.0 на самом деле просрочен на несколько месяцев. Попытка добавить дополнительные вещи, которые сами по себе требуют обсуждения, не состоится.

Что бы ни существовало в серии 0.24.x, это последний выпуск для Python 2, об этом уже давно было объявлено. Так оно и есть.

я не понимаю
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-444777018 . Не могли бы вы попробовать перефразировать/обобщить?

Я думаю, что Py2 против Py3 не имеет значения для 0.24.0.

Проблемы, связанные с EA, которые вы указали, я думаю, что все они будут в 0.24 (я не проверял их все). В основном это блокировщик на данный момент, но я недавно не просматривал невыполненную работу.

У меня не было времени заглянуть в уникальные.

@jreback

@h-vetinari pandas — почти полностью волонтерский проект. Таким образом, приоритеты проекта устанавливаются на основе консенсуса сообщества и работают над их достижением. У нас есть регулярные релизы вовремя; 0.24.0 на самом деле просрочен на несколько месяцев. Попытка добавить дополнительные вещи, которые сами по себе требуют обсуждения, не состоится.

Я все это знаю. Я просто говорю, что просрочка — плохая причина для спешки с выпуском, если некоторые из основных изменений еще не полностью разработаны (речь в основном идет об EA + регрессии).

Что бы ни существовало в серии 0.24.x, это последний выпуск для Python 2, об этом уже давно было объявлено. Так оно и есть.

Не знаю, что обсуждалось на других каналах, но на GH я увидел, что основным решением было 0.24->0.25->1.0 . Что касается PY2, в равной степени было сказано (и есть предупреждение об этом в Whatsnews), что выпусков PY2 не будет после 31 декабря 2018 года. Поддержка серии 0.24.0 для PY2 еще примерно 6-8 месяцев. поддержки PY2 (поскольку в противном случае перенос на ветку 0.24 был бы очень громоздким). Конечно, это правильный выбор, но я просто хотел предложить вместо этого оставить PY2 на очень стабильной версии 0.23.5.

@TomAugspurger

я не понимаю

24060 (комментарий). Не могли бы вы попробовать перефразировать/обобщить?

Я думаю, что Py2 против Py3 не имеет значения для 0.24.0.

Извините, это было неясно. Основными (взаимосвязанными) двумя пунктами являются:

  • не следует торопиться с 0.24 из-за заявленного крайнего срока (для поддержки PY2) 31 декабря.

    • перечислил некоторые проблемы для этого - некоторые из них (и многие другие связанные, которые я не отметил) были перемещены в «Приветствие вкладов» вместо версии 0.24.

    • упомянул, что 0.24 особенный из-за политики блокировки API до 1.0, и что я думаю, что это было бы жаль для .unique (но я понимаю, что я одинокий голос в глуши об этом один)

  • указать на несоответствие между окном предупреждения («Начиная с 1 января 2019 г., выпуски функций панд будут поддерживать только Python 3») и поддержкой серии 0.24 для PY2, а также предложением иметь версию 0.23.5 для PY2.

Проблемы, связанные с EA, которые вы указали, я думаю, что все они будут в 0.24 (я не проверял их все). В основном это блокировщик на данный момент, но я недавно не просматривал невыполненную работу.

В последнее время отставание значительно сократилось, не в последнюю очередь за счет того, что проблемы были перенесены в «Приветствие вкладов» (также для проблем EA). Это идет к моей точке срезать углы, чтобы получить это в ближайшее время.

При этом я довольно новичок в этой игре, и я не сомневаюсь, что основные разработчики получили общую картину и контролировали ее — но, надеюсь, указание на наблюдение не повредит.

У меня не было времени заглянуть в уникальные.

Справедливости ради, время разработки — очень ограниченный ресурс. Думаю, мне придется попытаться убедить всех в этом в стране после 1.0. ;-)

@h-ветинари

Я все это знаю. Я просто говорю, что просрочка — плохая причина для спешки с выпуском, если некоторые из основных изменений еще не полностью разработаны (речь в основном идет об EA + регрессии).

Если мы будем продолжать добавлять и добавлять, то релиз будет откладываться навсегда. Я начертил линию на песке. Вот как вы получаете продукт за дверь. Как только DTA выйдет полностью, мы сможем выпустить его. Так что это не так далеко. Конечно, мы могли бы проделать дополнительную работу и просто сказать, что 0.23.5 — это последний выпуск PY2 (и, конечно же, выпустить его). Но будет проще вернуться к стабильной ветке, то есть к серии 0.24.x.

Всегда есть что добавить в релиз, но этот уже самый большой из всех, что у нас когда-либо были. Есть неизбежные ошибки, и поэтому лучше сделать раньше, чем позже. Спасибо за ваш вклад. Здесь невозможно получить все основные изменения API. Вы совершенно правы в том, что время разработки — действительно ограниченный ресурс.

@jreback
Спасибо за ответ. Я понимаю, что вы хотите вынести это за дверь как можно скорее, что, конечно, достаточно справедливо.

Но будет проще вернуться к стабильной ветке, то есть к серии 0.24.x.

Кажется, я неправильно понял, что панды перестанут поддерживать PY2 с 1 января 2019 года... Возможно, тогда следует адаптировать это окно с предупреждением в whatsnews (« v.0.24.x будет последней серией, поддерживающей PY2; начиная с v.0.25.0 , панды будут только для python3 "...?)

RE: Прогресс CalendarDay https://github.com/pandas-dev/pandas/pull/22867#issuecomment -445433463

СДЕЛАТЬ
Добавьте все предупреждения об обесценивании (я ожидаю, что их будет довольно много). Это должно быть включено в следующее:

  • Арифметика дневных тиков с другими тиками, Timedeltas и DatetimeTZ
  • DatetimeIndex.shift (только для tz)

Миграция
План состоит в том, чтобы _Day (ранее CalendarDay) просто заменял Day после замены предыдущего поведения Day.

Беспокойство
Во время последнего чата разработчиков был интерес к тому, чтобы «D» был совместим аргументом/смещением freq как с Timedelta, так и с Datetime. Я не вижу ясного способа сделать это возможным, не добавляя много обезьяньих патчей.

Пример: timedelta_range(..., freq='D'); to_offset('D') вернет _Day в будущем, и это смещение должно будет увеличить Timedelta, но _Day + Timedelta является недопустимой операцией.

У кого-нибудь есть мнения по поводу проблемы согласованности timestamp/timedelta py2/py3?

Куча устаревших версий указана как подлежащая удалению в версии 1.0; должен ли 0.25.0 заменить 1.0 для некоторых из них?

У кого-нибудь есть мнения по поводу проблемы согласованности timestamp/timedelta py2/py3?

Можете ли вы подытожить этот вопрос? Думаю, в идеале мы бы просто следовали Python (какая бы версия ни работала). Но я не думаю, что полностью понимаю проблему.

Куча устаревших версий указана как подлежащая удалению в версии 1.0; должен ли 0.25.0 заменить 1.0 для некоторых из них?

Я думаю, что все они... Нужно обсудить это, некоторые, возможно, нужно будет подтолкнуть.

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

Недавно Timedelta была изменена, чтобы возвращать NotInplemented в случае, если она ранее поднималась. В результате его поведение py2 соответствует python, но отличается от поведения pandas py3.

Timestamp имеет открытый PR для внесения аналогичного изменения.

Как только py2 удален, изменение определенно правильное. До тех пор существуют противоречивые аргументы согласованности.

Мы должны либо получить Timestamp PR для 0.24.0, либо вернуть Timedelta PR до 0.24.0.

(печатать большими пальцами; LMk, если неясно)

я думаю, давайте вернем Timedelta, а затем добавим их обоих для 0,25/1,0 (только py3)

Перемещение этого комментария https://github.com/pandas-dev/pandas/pull/24227#issuecomment -446680041 сюда:

(для чего ИМО нам также понадобится как минимум пара недель в мастере)

[Том] Просто для проверки, мы должны сделать релиз-кандидат с DatetimeArray как можно скорее, верно? А потом 1-2 недели на мастере, пока нет RC?

Лично я бы не стал этого делать (если вы имеете в виду как можно скорее, например, через несколько дней). Я бы также оставил его как минимум на 2 недели в мастере, прежде чем делать RC. Сейчас на практике может и так будет..

Лично мне придется вернуться к dask/другим вещам после этого нажатия на datetimearray. Я надеялся, что мы сможем выпустить RC, пока я буду это делать.

Есть ли другие важные проблемы, которые я мог бы поднять, пока мы проходим этот раунд обзоров? Моя тарелка в настоящее время имеет

да, я думаю, мы должны объединить вещи (это упомянул Том), а затем посидеть в мастере хотя бы неделю или две.

Чтобы было ясно, я также хочу, чтобы это было выпущено как можно скорее, но мы также должны быть реалистами (например, я не думаю, что у нас будет окончательный релиз до конца года, как вы упомянули на fastparquet? даже если все блокирующие PR слиты за неделю, что кажется слишком быстрым (ИМХО)

Если у нас есть более длительный период RC, и мы все еще делаем некоторую дополнительную очистку после выполнения RC (и, возможно, делаем второй RC), я могу выполнить быстрое RC после слияния.
Но если мы видим RC как «готовый к выпуску с нашей стороны, если люди, пробующие RC, не сообщают о серьезных проблемах, мы можем сделать окончательный выпуск на основе этого», тогда у нас должны быть эти основные изменения в мастере для немного ИМО.

Думаю, у меня есть права на выпуск fastparquet. Есть обратное/прямое совместимое изменение, которое может быть выпущено сегодня.

Но если мы видим RC как «готовый к выпуску с нашей стороны, если люди, пробующие RC, не сообщают о серьезных проблемах, мы можем сделать окончательный выпуск на основе этого», тогда у нас должны быть эти основные изменения в мастере для немного ИМО.

Если у нас есть более длительный период RC, и мы все еще делаем некоторую дополнительную очистку после выполнения RC (и, возможно, делаем второй RC), я могу выполнить быстрое RC после слияния.

Это в основном то, где я нахожусь. Если предположить , что выдающиеся крупные реципиенты объединены на этой неделе (только при условии, не фактический срок), то мы превратимся до проблем с ними в ближайшие пару недель. Я надеюсь, что, выполнив RC (или два), мы с большей вероятностью обнаружим больше проблем, так что мы сможем быстрее выпустить финальный релиз более высокого качества.

Основная цена более раннего проведения RC заключается в том, что у нас больше не будет расползания масштаба, что может быть хорошо :)

Тем не менее, я не думаю, что проводить RC в любое время, скажем, с 20 по 27 число, это хорошая идея из-за праздников. Так что я также согласен сделать это вскоре после Нового года.

все звучит хорошо; RC первый год;

@jreback @TomAugspurger @jorisvandenbossche
Примете ли вы PR для #22724 до отсечки? Я знаю, что вы хотите избежать расползания масштаба и как можно скорее выпустить это за дверь, но я исхожу из того, что касается согласованности, и я думаю, что это изменение может быть полезным как можно раньше, а не позже. Думал спросить, прежде чем тратить время.

Кстати говоря, у вас уже есть идея, какова будет политика в отношении критических изменений между версиями 0.24 и 0.25? Будут ли они полностью заблокированы или мастер сразу же перейдет на 1.0.0.dev, а v0.25 будет использовать бэкпорты?

@jreback @TomAugspurger @jorisvandenbossche

Кстати говоря, у вас уже есть идея, какова будет политика в отношении критических изменений между версиями 0.24 и 0.25? Будут ли они полностью заблокированы или мастер сразу же перейдет на 1.0.0.dev, а v0.25 будет использовать бэкпорты?

Повторно спрашивая об этом, поскольку - в случае, если нарушение PR будет заблокировано до выпуска v.0.25 - я бы приостановил всю работу по взлому PR.

очищая колоды, пожалуйста, не отмечайте 0.24.0, если только не произойдет немедленное слияние. за исключением уборки, которую все еще делают @jbrockmendel и @TomAugspurger

в идеале может ли rc1 сказать на следующей неделе, @TomAugspurger ?

Я тоже думал на следующей неделе. Сейчас просматриваю отставание.

В пятницу, 4 января 2019 г., в 8:00 утра Джефф Ребак уведомления[email protected] написал:

очищая колоды, пожалуйста, не отмечайте 0.24.0, если только не произойдет немедленное слияние.
за исключением уборки, которую все еще делает @jbrockmendel
https://github.com/jbrockmendel и @TomAugspurger
https://github.com/TomAugspurger

в идеале мог бы сделать rc1, скажем, на следующей неделе, @TomAugspurger
https://github.com/TomAugspurger ?


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-451450878 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABQHIt1WfzSQoOTnbRYdwYdvo6Qo1Zy5ks5u_16OgaJpZM4Y9wcW
.

да я тоже

Повторно спрашивая об этом, поскольку - в случае, если нарушение PR будет заблокировано до выпуска v.0.25 - я бы приостановил всю работу по взлому PR.

Я предпочитаю, чтобы единственными изменениями API с 0.25 -> 1.0, нарушающими API, было удаление ранее устаревших функций. Затем пользователи могут

  1. Убедитесь, что все работает гладко на 0.25.x
  2. Исправьте любые FutureWarnings от панд
  3. Уверенно обновитесь до 1.0

Во IIRC на последнем собрании разработчиков было достигнуто слабое согласие с этим.

@TomAugspurger означает, что мы все еще делаем

Я толком не помню, что мы об этом говорили, только смутное воспоминание из летнего спринта, что мы уже хотели, чтобы все устаревшие версии были в 0.24, а не добавлялись в 0.25 (хотя резюме в https://github.com/pandas- dev/pandas/wiki/Pandas-Sprint- (июль 2018 г.) говорит только о том, что все устаревания в 0.25 и их удаление в 1.0).

Извините, если я неправильно прочитал. Ваше смутное воспоминание совпадает с моим смутным воспоминанием об устаревании версии 0.25.0 :)

Хотим ли мы пересмотреть эту политику? IOW, хотим ли мы разрешить новые устаревания в 0.25.0, которые либо

  • Удалено в версии 1.0 (у сообщества не было много времени на адаптацию)
  • Поддерживается для 1.0 и удаляется в 2.0 (если мы делаем semver)

у нас должен быть звонок по плану после того, как 0.24 выйдет за дверь

Я хотел бы сократить RC1 через ~ 4 часа после слияния https://github.com/pandas-dev/pandas/pull/24708 . Есть возражения?

Нам нужно будет обсудить, насколько консервативно мы относимся к слиянию PR в течение периода RC. Я не помню, что мы делали в прошлый раз (только PR, которые исправляют ошибки конкретно с RC? Или "мелкие" вещи в порядке?).

хорошо RC, да мелочи в порядке. Если у нас будет большой, то, возможно, понадобится RC2

Тегирование сейчас и прохождение локальных тестов перед отправкой тега. Напиши мне, если найдешь блокировщик в последнюю минуту.

@TomAugspurger, вы упомянули, что собираетесь написать сообщение в блоге для релиза, но я полагаю, только для финального релиза?
В этом случае было бы хорошо иметь несколько основных моментов (я начал набрасывать некоторые из них); в файле whatsnew может потребоваться некоторая очистка.

Есть идеи, сколько времени это займет? Я как раз собирался поставить тег :)

Тем не менее, я могу восстановить документы, которые будут отправлены на веб-сервер из другого коммита.

У вас есть немного больше времени, так как я думаю, что мне нужно немного поработать над нашим рецептом conda-forge, чтобы гарантировать numpy >= 1.12 :)

Да, не жди меня. У меня есть другая работа, которую нужно закончить в первую очередь.

В ПОРЯДКЕ. помечен.

В пятницу, 11 января 2019 г., в 9:13 Йорис Ван ден Босше <
уведомления@github.com> написал:

Да, не жди меня. У меня есть другая работа, которую нужно закончить в первую очередь.


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453548795 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABQHIsamTvr2YaLm68tQDFCX40_nraSTks5vCKo3gaJpZM4Y9wcW
.

Я начал просматривать файл whatsnew, чтобы извлечь основные моменты, и уже подумал:

  • Рефакторинг внутренней обработки пользовательских типов данных:

    • Лучшая интеграция интерфейса ExtensionArray

    • Period и Interval теперь можно хранить в столбцах Series/DataFrame (раньше только в Index)

  • Новый атрибут .array в Series и Index для доступа к базовым значениям и метод to_numpy для преобразования в пустые массивы.
  • Необязательное целое число NA
  • редкие изменения

Есть ли какая-то изюминка, о которой стоит упомянуть во всем рефакторинге, похожем на дату и время? (помимо «рефакторинга внутренней обработки пользовательских типов данных»)

Стоит ли упомянуть какие-либо другие новые функции или изменения?

На https://github.com/pandas-dev/pandas/releases/tag/v0.24.0rc1 есть несколько.

В пятницу, 11 января 2019 г., в 9:51 Йорис Ван ден Босше <
уведомления@github.com> написал:

Я начал просматривать файл whatsnew, чтобы извлечь основные моменты, и
уже придумал:

  • Рефакторинг внутренней обработки пользовательских типов данных:

    • Лучшая интеграция интерфейса ExtensionArray

    • Период и интервал теперь можно хранить в Series / DataFrame.

      столбцы (раньше только в индексе)

  • Новый атрибут .array в Series и Index для доступа к базовому
    значения и метод to_numpy для преобразования в массивы numpy.
  • Необязательное целое число NA
  • редкие изменения

Есть ли какая-то изюминка, о которой стоит упомянуть во всем рефакторинге, похожем на дату и время?
(помимо «рефакторинга внутренней обработки пользовательских типов данных»)

Стоит ли упомянуть какие-либо другие новые функции или изменения?


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-453561740 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABQHIh4Abyv5aEhn2vAA7KAJziTL75Rkks5vCLL7gaJpZM4Y9wcW
.

Двоичные файлы создаются, а HTML-документы размещены на http://pandas.pydata.org.

Объявление будет отправлено позже сегодня, как только двоичные файлы будут готовы.

Колеса Mac и Linux находятся на PyPI. Пакеты Conda поступают в conda-forge, и я разослал электронное письмо с объявлением.

На https://github.com/pandas-dev/pandas-release есть несколько вещей, которые нужно исправить. Некоторые из них специфичны для RC, поэтому я не слишком беспокоюсь о них. Я постараюсь сгладить все окончательные проблемы во время работы над окончательным релизом, а затем, надеюсь, кто-нибудь еще сможет попробовать что-то, чтобы увидеть, какие машинно-специфические вещи я там случайно закодировал.

нет колеса Windows для 0.24.0rc1?

Я не уверен, что @cgohlke обычно

Я готов. Сборка pypy не удалась...

Спасибо @cgohlke , колеса Windows теперь доступны на PyPI.

Вероятно, мы должны сделать 0.24.0 на этой неделе. Есть возражения? Какие-то блокираторы?

Я не знаю, сделаю ли я https://github.com/pandas-dev/pandas/pull/24674 . На этой неделе будет не так много времени.

нет возражений - хотелось бы получить то, что в настоящее время отмечено для 0.24.0, но если через пару дней их не будет, то можно отложить

@TomAugspurger все проблемы и PR чисты для 0.24.0

Я сделаю быстрый документальный PR, добавив метку эксперимента в DatetimeArray и
TimedeltaArray с предупреждением о том, что .dtype как ожидается, изменится в
будущее.

В среду, 23 января 2019 г., в 7:03 Джефф Ребак уведомления[email protected]
написал:

@TomAugspurger https://github.com/TomAugspurger все проблемы и PR
чистый для 0.24.0


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Планирование слияния

и тег вскоре после этого. Что-нибудь еще из РК?

В среду, 23 января 2019 г., в 7:15 Том Аугспургер [email protected]
написал:

Я сделаю быстрый документальный PR, добавив метку эксперимента в DatetimeArray и
TimedeltaArray с предупреждением о том, что .dtype как ожидается, изменится в
будущее.

В среду, 23 января 2019 г., в 7:03 Джефф Ребак уведомления[email protected]
написал:

@TomAugspurger https://github.com/TomAugspurger все проблемы и PR
чистый для 0.24.0


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pandas-dev/pandas/issues/24060#issuecomment-456793566 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABQHImKD-UhxOjifdIssgpzK7mRPh69fks5vGF2mgaJpZM4Y9wcW
.

Вплоть до

Если у людей есть быстрые мысли о # 24926 (удаление IntervalArray из верхнего уровня, просто использование pd.arrays.IntervaArray ), то быстрый +/-1 там был бы полезен.

@TomAugspurger Перед тем, как пометить, можете ли вы сделать последнюю настройку даты в документах whatsnew? (сейчас еще январь ХХ) Или в коммите релиза

Все слилось я думаю!

Спасибо, тег.

мило @TomAugspurger

Ууу! Поздравляем. Спасибо за всю тяжелую работу. Очень жду релиза.

sdist и двоичные файлы доступны на PyPI и conda-forge. Anaconda сейчас работает по умолчанию.

Всем спасибо.

И спасибо!

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

andreas-thomik picture andreas-thomik  ·  3Комментарии

MatzeB picture MatzeB  ·  3Комментарии

matthiasroder picture matthiasroder  ·  3Комментарии

Abrosimov-a-a picture Abrosimov-a-a  ·  3Комментарии

swails picture swails  ·  3Комментарии