Pandas: DEPR: очистить список устаревших версий из предыдущих версий.

К вашему сведению, cols также используется в to_csv и to_excel .

@TomAugspurger хорошая мысль!

@jsexauer , не могли бы вы сделать еще один PR, чтобы объявить устаревшим cols в to_csv / to_excel (например, сделать то же, что вы сделали в сводке, по-прежнему принять это, но предоставить предупреждение и заменить columns )

Конечно, нет проблем.

@jreback Я подумал, теперь, когда мы также объявляем это устаревшим в to_csv и to_excel , не должны ли мы продлить этот цикл устаревания более чем на один выпуск? Потому что я не знаю, обновляют ли большинство пользователей свою версию каждый выпуск.

Я согласен с @jorisvandenbossche - было бы разумно указать дополнительный цикл выпуска в качестве буфера.

конечно
просто сохраняйте открытые вопросы в качестве напоминаний
Я только что удалил старый синтаксис в сортировке, я думаю, примерно с <0,8!

хотя, возможно, изменит их на 0,16, так что они в правильном месте

Я добавил разделы по версиям в исходный пост. Давайте оставим это как текущую проблему устаревания (если нет возражений. Я открыт для конкретных проблем в каждом выпуске)

@jsexauer хочу сделать PR для тех, кто указан для 0.15.0

Конечно будет делать

В категориальном есть несколько устаревших, что приведет к сбою юнит-тестов.

Возможно, это был бы хороший способ отслеживать это устаревание:

# in testing.py
def fail_after_whatever_comes_first(date, pandas_version):
     from dateutil import parser
     import datetime
     latest = parser.parse(date)
     self.assertFalse(datetime.now() >= latest)
     self.assertFalse(LooseVersion(pd.__version__) >= pandas_version)

а затем используйте это как последний тест в модульных тестах для устаревших методов/свойств/аргументов

@JanSchulz , что ты здесь предлагаешь?

Мое предложение состояло в том, чтобы поместить обработку устаревания в сам код, а не в отчет об ошибке :-)

вставка фактического кода - не очень хорошая идея (если это ЕДИНСТВЕННОЕ место) и, как правило, просто загромождает вещи. Вы должны каким-то образом отслеживать то, что может произойти (с явным напоминанием), следовательно, проблема НАМНОГО лучше, и как мы это делаем.

@jsexauer какие-либо результаты для 0.15.0? (или, пожалуйста, отредактируйте верхнюю часть и перейдите к 0,16)

@jreback Я написал код, но сейчас он не проходит модульные тесты. Нужно вернуться и выяснить, нужно ли обновлять тесты или я неправильно удалил устаревание. У вас есть временная шкала, к которой вы хотели бы внести изменения?

@jsexauer , какие изменения у вас частично работают?

Вот ветка, в которой они находятся: https://github.com/jsexauer/pandas/tree/fix6581_015 .
Вот отчет об ошибке модульного теста: https://travis-ci.org/jsexauer/pandas/jobs/35994074

ааа, ладно, как насчет того, чтобы просто сделать деуровень и переместить коробку на 0.16.0, а затем

@TomAugspurger , @jorisvandenbossche

@jsexauer хочешь просто пиарить делевел?

@jsexauer , давайте увеличим это до 0,16 (хотя теперь я соглашусь на удаление delevel, если вы можете)

Я напишу один очень быстро и отправлю его в течение часа

@jsexauer gr8 спасибо. Пожалуйста, отредактируйте проблемы выше и переместите на 0.16.0 остальные 0.15.0.

Я собирался начать работу над устареванием 0.16 в ближайшее время. Хотел проверить и посмотреть, хотите ли вы, чтобы все, что перечислено в 0.16, устарело. @jreback

Я думаю, что все в списке хорошо идти.

Я обновил все устаревшие проблемы. Я думаю, что все, что <= 0.14.0, должно быть сделано в 0.17.0. Все требуют упоминания в разделе Previous Deprecations . Некоторым может понадобиться примечание к документу, если оно достаточно «важно» (например, это было удалено в версии ???) и / или более заметное упоминание в Whatsnew (например, в основных моментах)

Если честно, хорошо и с 0.15.0.

любой, кто заинтересован в размещении PR для любого из этих удалений устаревания. Все, что < 0,14, точно нормально. что-нибудь еще, пожалуйста, ЛМК.

@TomAugspurger

мы можем сделать PR для этого? (первый вверху)

 boxplot #7096 (0.14.0)
 change default of return_type from None to 'axes'
 update return_type section in visualization.rst

Конечно, сделаю PR сегодня вечером или в воскресенье.

Я обновил список вверху, и есть некоторые устаревшие версии 0.15, которые могут быть удалены в 0.19.0 (а некоторые из 0.16.0, возможно, также заслуживают внимания).

@jorisvandenbossche , @jreback : Что представляют собой удаления «возможно» устаревания? Это те, которые можно сделать в 0.19.0 , но они не нужны? Или что мы еще не уверены в них?

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

Немного смущен тем, что происходит с устареванием операций индекса «+» / «-». Помимо удаления всех предупреждений, эти операции просто переназначаются для выполнения арифметического сложения/вычитания --> изменение - это просто изменение API для выполнения арифметических операций? Или эти функции удаляются? Мое предположение первое, но я хотел уточнить.

@jreback , @jorisvandenbossche : теперь, когда #13611 было объединено, вы можете отметить удаление flavor в этом списке!

Кроме того, просто любопытно, по какой причине мы сейчас удаляем SparsePanel ?

Ну, SparsePanel вызывает некоторые раздражающие предупреждения об устаревании addtl.

@jreback : Не могли бы вы поставить галочку в поле return_type='frame'|'series' в списке «возможно»? Мой PR для удаления, который был объединен пару дней назад (#13701).

Еще одна гнида: # 13735 @jorisvandenbossche следует переместить в раздел For 0.19.0 IINM (а не «Будущий выпуск»)

Немного смущен тем, что происходит с устареванием операций индекса «+» / «-». Помимо удаления всех предупреждений, эти операции просто переназначаются для выполнения арифметического сложения/вычитания --> изменение - это просто изменение API для выполнения арифметических операций? Или эти функции удаляются? Мое предположение первое, но я хотел уточнить.

Да, действительно, переназначение на арифметические операции. Если у вас будет время сделать пиар, всегда пожалуйста :-)

@jreback : для раздела 0.17 generate_bq_schema больше нет в кодовой базе. Вероятно, удалено при переходе на pandas-gbq ?

@gfyoung

Для раздела 0.17 generate_bq_schema больше не находится в кодовой базе. Наверное удалили при переходе на pandas-gbq?

отметил это

@jreback , @jorisvandenbossche : Можно ли добавить что-то о политике удаления устаревания в исходный выпуск? Это может быть полезно, если кто-то хочет работать в этом направлении (например, сколько версий назад должно быть устаревание, прежде чем его можно будет удалить?)

Хорошая идея. Я думаю, что в настоящее время мы удаляем устаревание, например, 0,17 в 0,20. Это означает, что мы сохраняем устаревание для 3 выпусков (устаревшее в 0.17 -> предупреждения в 0.17, 0.18, 0.19 -> изменено в 0.20)?

Да, три основных релиза назад... это верно, IINM.

@jorisvandenbossche : Хотим ли мы каждый раз менять веху? Ваш звонок.

Менять не так уж и сложно :-)
Я бы поставил его на эту веху, тогда станет ясно, что здесь есть работа, которую нужно проделать для этого релиза. Как только все для этого релиза будет сделано, или когда придет время для rc, и мы больше не будем добавлять устаревшие версии, мы просто изменим его на следующий релиз.
Я вижу, что @jreback поместил его на веху «Администратор», но я думаю, что описанный выше рабочий процесс в порядке?

@jorisvandenbossche : этот рабочий процесс меня устраивает. Теперь стало намного яснее, с какими устаревшими решениями нужно бороться и когда (надеюсь, другие согласятся! 😄)

@gfyoung К вашему сведению, я хочу увидеть, когда мы устарели pd.options.line_width/height . Их можно удалить (в 0.21.0), я уверен

@jreback : Ты абсолютно прав. 0,11 и 0,12 соответственно. 😢

если кому интересно могу убрать любой из .17/.18/.19 в 0.22

Заметив пару функций/методов, не прошедших тесты, заслуживают внимания:

indexing.is_index_slice
Block.reindex_axis
_большинство_ из SingleBlockManager.reindex

@jbrockmendel : заслуживают внимания? Абсолютно! Все это устарело? Я не вижу их всех в списке. Я определенно хотел бы убедиться, что неустаревшие из них получат больше охвата, если это возможно.

cc @gfyoung Я обновил, чтобы удалить большинство из 0.20.0

Я не думаю, что мы уже должны удалять вещи, которые устарели в 0.20. Я знаю, что мы увеличили 0.22 до 0.23, но я не думаю, что в связи с устаревшими версиями мы должны рассматривать выпущенную версию 0.22 как «крупную версию» в этом отношении (поскольку в ней нет новых функций, и в принципе она не должна задерживать выпуск 0.23).
Версия 0.20 была выпущена только в мае 2017 года, поэтому этим устаревшим версиям не исполнится и года.

Хм... достаточно честно. Я начал только потому, что заметил, что @jreback переместил кучу под 0.23 .

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

нет, нам нужно перенести расписание вверх

@jreback : Итак ... возобновите удаление устаревших вещей из 0.20.0 ? Я вижу, что исходная проблема не была изменена с тех пор, как @jorisvandenbossche изменил ее.

@jreback , вы не совсем ясно выразились, я могу интерпретировать «нет необходимости сдвигать расписание вверх» как «нет необходимости уже начинать удалять вещи с 0.20». Но я думаю, что это вы отметили эти устаревшие версии 0.20 как готовые к удалению?

@jorisvandenbossche да, я изменил это. Я не вижу причин ждать их удаления (кроме некоторых, которые я специально отметил). если у вас есть те, которые, по вашему мнению, не следует удалять до версии 1.0, пожалуйста, переместите их туда, где находятся ix/Panel.

Как я сказал выше, я думаю, что ни одно из устаревших версий 0.20 не должно быть удалено в 0.23 (речь идет о тех, кто находится в первом списке 0.20, а не о ix/Panel). ИМО они должны быть удалены только в следующем основном выпуске, будь то 0.24 или 1.0, это не имеет большого значения.

Наше неявное правило состояло в том, чтобы поддерживать устаревание как минимум для двух основных выпусков (но, возможно, нам следует документировать это ожидание более явно), и при подсчете этих основных выпусков я не думаю, что мы должны учитывать 0,22. Этим устареваниям не исполнится и года, когда будет выпущена версия 0.23.

Я не думаю, что мы должны считать 0,22. Этим устареваниям не исполнится и года, когда будет выпущена версия 0.23.

Согласен с @jorisvandenbossche. Самое важное для нижестоящих библиотек — это календарное время между объявлением чего-либо устаревшим и его удалением. Поскольку 0.22 ускорил наш график выпуска, я думаю, нам следует отложить удаление того, что было запланировано для 0.23.

и 1 рассматриваемый банкомат устарел в 0.19
так что теперь надо удалять

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

@TomAugspurger : отказ от поддержки, сделанный в # 16617 ... похоже, что в какой-то момент его удалили? Это все еще находится в очереди на удаление в 0.25.0 или план изменился?

@gfyoung PR, на который вы ссылаетесь, никогда не сливался?

@jorisvandenbossche : Хорошее замечание - упс 🙂. В таком случае, похоже, мы не будем удалять это в ближайшее время. При этом мой вопрос остается в силе относительно будущего устаревания и удаления этих методов.

При этом мой вопрос остается в силе относительно будущего устаревания и удаления этих методов.

Весь класс SparseSeries устарел, поэтому я не думаю, что есть необходимость в дальнейшем осуждать определенный случай в его конструкторе.
Теперь для этого есть DataFrame.sparse.from_spmatrix .

Обратите внимание, что я закрепил это на GH после нашего вчерашнего разговора с разработчиками. Я считаю, что мы действительно хотим удалить все, что считалось устаревшим до 1.0, для нашего релиза 1.0, поэтому PR для этого от сообщества, безусловно, приветствуется.

@mroeschke , не могли бы вы обратить внимание на удаление # 20584?

Определенно @jbrockmendel. Сможет сделать.

@mroeschke возглавляет это, и 13777 ведут себя плохо, получая несколько правок за короткий промежуток времени. в этом случае, я думаю, он молча отменил сделанное вами редактирование roll.apply

Спасибо за хедз-ап @jbrockmendel. Давайте посмотрим, если 2-й раз очарование.

@TomAugspurger , у вас есть сравнительное преимущество в # 23767?

@mroeschke IIRC #22644 был твоим, хочешь закончить?

@WillAyd , разве ты уже не позаботился о #18731? если да, пожалуйста, обновите списки флажков

@pandas-dev/pandas-core Некоторые из них неоднозначны и могут потребовать обсуждения/разъяснения:

• [ ] #18347 .add_suffix/.add_prefix — в ходе обсуждения создается впечатление, что это не может быть объявлено устаревшим в конце концов. Можем ли мы подтвердить статус по этому вопросу?
• [ ] #21930 Series.compress — удаление разрывает np.compress(series) . Нам все равно?
• [ ] #27112 Series.item и Index.item — недавнее обсуждение отмены устаревания item . Где мы приземлились на это?

• +1 при повторном включении .item()
• +0 за отказ от поддержки .add_suffix/.add_prefix, IIRC не верит, что он действительно устарел
• хорошо, если удалить .compress() , это все равно не очень полезно даже в numpy, особенно для 1-D, где это просто индексация.

add_prefix / add_suffix никогда не считались устаревшими, поэтому их удаление не обсуждается. Кто-то может открыть новую проблему (или найти существующую) для дальнейшего обсуждения ее устаревания, но, поскольку речь идет об удалении действительно устаревших вещей, мы удалили ее из списка выше.

Я думаю, что со взломом np.compress() у меня все в порядке.

Давайте обсудим item в https://github.com/pandas-dev/pandas/issues/29250 (я за то, чтобы хотя бы часть этого сохранить)

@jorisvandenbossche есть пара из них, которые я пробовал и не мог понять. Могу ли я заставить вас взглянуть или предложить кого-то, кого я должен прослушивать? Во-первых, это how fill_method в resample (требуется ссылка на GH). Второй — номер 26403.

Второй — номер 26403.

Только что открыл PR для этого, см. # 29955

Во-первых, как fill_method в ресемпле (требуется GH ref)

Это устаревание было введено в https://github.com/pandas-dev/pandas/pull/11841. Это могут быть остатки, которые не были удалены в https://github.com/pandas-dev/pandas/pull/20782.

@mroeschke есть еще какие-нибудь, кого ты хочешь назвать бабками, прежде чем я поеду в город?

@jbrockmendel На этой неделе я, вероятно, буду медлить с устареванием. Действуй.

Я перенес устаревание, которое мы делаем в 1.0, в новую проблему: https://github.com/pandas-dev/pandas/issues/30228 (поэтому аналогичная проблема, чтобы вести журнал устареваний, но начиная новый для 1.х)

Все перечисленные устаревания были устранены. Спасибо всем!