Pandas: ENH: разрешить выбор новых типов dtypes для подпрограмм ввода-вывода с помощью ключевого слова для подпрограмм ввода-вывода.

@jorisvandenbossche , это вероятно для 1.0? Я изначально предпочитаю добавить это в будущем (как вариант, скажем, в 1.1).

Это, конечно, не критично для выпуска, поэтому давайте перейдем к этапу.

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

Вариант типа use_new_dtypes=True/False последовательно для всех функций, создающих фреймы данных / серии?
Или лучше название, так как «новый» не очень наглядно. use_nullable_dtypes может не полностью покрывать, например, строки, поскольку раньше они уже допускали значение NULL.

Я хотел бы возразить, что если вы хотите, чтобы люди использовали новые типы dtypes, и особенно pd.NA , это становится очень важным, потому что IMHO, большинство недостающих значений вводятся, когда люди читают данные. Так что, если вы не измените процедуры ввода-вывода, pd.NA вряд ли можно будет использовать.

Что касается имен, может быть use_extension_dtypes ??

Что мне не нравится в use_extension_dtypes это то, что он звучит как расширение pandas, что здесь не так. Надеюсь, что в какой-то момент это будут dtypes по умолчанию.
(Я знаю, все это называется Extension .., но все же).

Как насчет use_distinct_dtypes ?

@jorisvandenbossche Я начал смотреть на это, и если бы мы сделали это для каждого читателя, это могло бы DataFrame.as_nullable_types() , который принимал бы DataFrame и преобразовывал любой столбец в тип, допускающий значение NULL. Затем, если вы использовали какой-либо ридер, который не использовал новые типы, вы могли бы преобразовать все DataFrame в одну строку, так что у вас может быть df = pd.read_csv('filename.csv').as_nullable_types() или df = pd.read_excel('filename.excel').as_nullable_types() и т. Д. . Правила могут выглядеть примерно так:

1. Если dtype - это объект, преобразовать в строку. Если это не удается, оставьте это в покое.
2. Если dtype имеет значение float, попробуйте преобразовать его в логическое значение. Если это не удается, попробуйте преобразовать в Int64. Если это не удается, оставьте это в покое.

Моя цель здесь - упростить людям использование новых StringDType , Int64DType и BooleanDType . Если мы не сделаем что-то подобное, я не думаю, что эти типы будут задействованы, потому что отсутствующие значения обычно встречаются при чтении данных, и болезненно указывать dtype для каждого столбца при чтении данных с большим количеством столбцы.

если бы мы сделали это для каждого читателя, это могло бы потребовать много работы из-за всех различных реализаций читателя

Я думаю, что если мы хотим иметь эффективные методы, нам, вероятно, все равно придется закончить с реализацией, ориентированной на читателя. Но это, конечно, не означает, что все читатели должны поддерживать его изначально, мы можем начать с самых важных и попросить других преобразовать его после прочтения. Например, я планировал работать над считывателем паркета, который напрямую выдает вам целые числа, допускающие значение NULL (что позволяет избежать копирования и ненужного обхода для плавания). Все, что нужно сказать: я думаю, что в некоторых случаях по-прежнему полезно иметь его в качестве опции для чтения.

Но при этом вспомогательный метод / функция для преобразования существующего фрейма данных в новый фрейм данных с использованием типов, допускающих значение NULL, звучит как хорошая идея, которая в любом случае будет полезна.
Концептуально это чем-то похоже на DataFrame.infer_objects («Попытка вывести лучшие dtypes для столбцов объекта.», За исключением того, что здесь мы хотим вывести лучшие dtypes для всех столбцов)

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

Я мириться PR реализующий use_nullable_dtypes опцион на read_parquet а именно: https://github.com/pandas-dev/pandas/pull/31242

В PR, добавляя опцию к read_parquet , мы ведем более общую дискуссию о такой опции в IO и более общую информацию о том, чего ожидать от такой опции (а не только от имени), поэтому перемещая его сюда.

@jreback и @WillAyd упомянули, что они предпочитают use_extension_dtypes чем use_nullable_dtypes , на что я ответил:

Для меня основная причина не использовать use_extension_dtypes : 1) эта опция не запускает для возврата типов расширений в целом. Например, он не запускает для возврата категориальный или datetimetz (поскольку они по умолчанию возвращаются pyarrow), и он не запускает для возврата периода или интервала (они могут быть возвращены на основе метаданных, сохраненных в файле parquet / расширении pyarrow типы); в обоих случаях типы расширений будут возвращены даже с use_extension_dtypes=False . Напротив, я нахожу use_nullable_dtypes более ясным в передаче намерения *.
Кроме того, и более семантически, типы «расширения» могут дать представление о «внешних» типах расширения (но это вообще проблема с термином, поэтому здесь не так актуально).

* Я думаю, нам понадобится некоторая терминология для обозначения «типов, которые используют pd.NA качестве индикатора пропущенного значения» . Также для нашего общения (и при обсуждении) этого, поскольку в документации и т. Д. Было бы хорошо иметь термин для этого, который мы могли бы постоянно использовать. Я думаю, что "nullable dtypes" - это вариант для этого (мы уже некоторое время используем "nullable integer dtype" в документации), хотя, конечно, не идеальный, поскольку, строго говоря, другие dtypes также "nullable" (float, object, datetime) , просто по-другому.
Возможно, это более общее обсуждение поможет нам впоследствии найти совпадающие имена ключевых слов.

ответ @WillAyd

Конечно, в качестве быстрых контраргументов:

• Семантика неясна для конечного пользователя; Я бы подумал, что большинство считает np.float допускающим значение NULL, что не повлияет на
• Некоторые аргументы в пользу его ясности характерны для паркета, но я думаю, что они станут более неоднозначными, если мы повторно используем одно и то же ключевое слово для других парсеров (что, я надеюсь, мы будем использовать)
• Если в будущем мы добавим больше типов расширений, которые ориентированы не только на обработку NA, тогда нам придется добавить еще одно ключевое слово поверх этого для синтаксического анализа, что только усложнит задачу.

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

_ответ @WillAyd_

• Если в будущем мы добавим больше типов расширений, которые ориентированы не только на обработку NA, тогда нам придется добавить еще одно ключевое слово поверх этого для синтаксического анализа, что только усложнит задачу.

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

Я согласен, что это веский аргумент не использовать as_nullable_dtypes . Вот несколько идей:

• as_NA_dtypes (поддерживающие pd.NA )
• as_modern_dtypes (поскольку все, что мы хотели бы поддерживать, было бы самым современным)
• as_endorsed_dtypes (тогда мы сможем определить, какие из них одобрены / рекомендуются)

Надеюсь, это стимулирует обсуждение!

Спасибо @WillAyd за эти аргументы. Исходя из этого, кажется, что нам все еще нужно обсудить / уточнить, какой точной цели мы хотим достичь с помощью такой опции.

Семантика неясна для конечного пользователя; Я бы подумал, что большинство считает np.float допускающим значение NULL, что не повлияет на

Да, это то, что я упомянул о том, что "nullable" не является идеальным. Но это общая проблема, связанная с этими типами. И, как упоминалось выше, я думаю, нам нужно найти для этого какой-то термин.
Если мы четко определим, что мы имеем в виду под «nullable dtype» в документах, и будем последовательно использовать его для этой цели во всей документации, я думаю, что такой термин может работать (IMO, это, по крайней мере, лучше, чем отсутствие согласованного термина).
Кроме того, в какой-то момент мы могли бы захотеть иметь dtype с плавающей запятой, который использует pd.NA качестве пропущенного значения. Также нам нужен термин, чтобы отличить его от "классического" типа float dtype ("nullable float dtype"?)

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

Parquet - это один из форматов, который содержит больше всего информации о типах, поэтому различие между типами расширения в целом и типами, допускающими значение NULL, в частности, действительно наиболее актуально. При чтении, например, csv, вы действительно не можете получить категоричность. Но только паркетом дело не ограничивается. read_feather и read_orc также основаны на pyarrow, поэтому имеют одинаковую поддержку типа. Вы можете получить категории из read_stata и read_spss , вы можете получить datetimetz из read_sql и (возможно?) read_excel

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

Да, если эти новые типы расширений не используют pd.NA в качестве индикатора пропущенного значения, они намеренно не подпадают под это ключевое слово. Эта проблема здесь действительно касается тех типов dtypes, которые используют pd.NA, поскольку они имеют другое поведение для операций с отсутствующими значениями.
Лично я бы сказал, что мы не должны добавлять новые типы расширений, которые не используют pd.NA , но это уже другое обсуждение. Обсуждать такой гипотетический случай тоже сложно; один конкретный пример, который возник, - это что-то вроде struct / json: они, вероятно, в любом случае не могут быть сохранены в типичных форматах файлов, таких как csv (а также, мы, вероятно, могли бы использовать pd.NA как отсутствующее значение там).

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

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

Я согласен, что это веский аргумент не использовать as_nullable_dtypes.

Чтобы выделить один пункт из моего длинного сообщения выше, который отвечал по этому поводу: IMO, если такой новый dtype не использует pd.NA, он не должен подпадать под это ключевое слово. Так что если мы сделаем это (конечно, спорно), то какое бы имя мы ни придумали (например, use_NA_dtypes ), будет точно такая же проблема.

Немного другое направление, но как насчет чего-то вроде na_float_cast=True по умолчанию? Я думаю, более четкое намерение, а также не заставляет использовать расширение dtype, если значения NA действительно не обнаружены, что может помочь сэкономить память

Немного другое направление, но как насчет чего-то вроде nan_float_cast = True по умолчанию? Я думаю, более четкое намерение, а также не заставляет использовать расширение dtype, если значения NA действительно не обнаружены, что может помочь сэкономить память

Это зависит от поведения опции. Прямо сейчас я думаю, что целью было использовать, например, целочисленный dtype, допускающий значение NULL, для всех целочисленных столбцов, а не только для тех целочисленных столбцов, у которых отсутствуют значения и которые в противном случае были бы преобразованы в float. (Кроме того, для логических значений они приводятся к объекту прямо сейчас, если есть числа с плавающей запятой)

Верно, что невыполнение этого для всех столбцов может сэкономить память, но лично я бы предпочел сделать это для всех столбцов: 1) вы получите согласованный результат в зависимости от «логического» типа вашего столбца, а не от наличия пропущенных значений ( например, если чтение только в части файла, это уже может отличаться 2) отсутствующие значения также могут быть введены после чтения (например, переиндексирование, слияние, ..), а затем наличие целочисленного dtype, допускающего значение NULL, гарантирует, что он не будет приведен к тогда float, даже если в исходных данных не было nans

Это зависит от поведения опции. Прямо сейчас я думаю, что целью было использовать, например, целочисленный dtype, допускающий значение NULL, для всех целочисленных столбцов, а не только для тех целочисленных столбцов, у которых отсутствуют значения и которые в противном случае были бы преобразованы в float. (Кроме того, для логических значений они приводятся к объекту прямо сейчас, если есть числа с плавающей запятой)

Да, я согласен - разъяснение этого намерения определенно движет этим.

Я не думаю, что стоит добавлять маску без необходимости - это определенно может иметь нетривиальные последствия для памяти. Если моя простая математика подходит для 10 миллионов строк на 10 столбцов
блок целочисленных значений, добавляющий маску, потребует как минимум 100 МБ памяти больше

Не думаю, что стоит добавлять маску без надобности

Но вместо того, чтобы ограничивать столбцы, которые будут преобразованы в типы с масками / значениями NULL, с помощью обсуждаемой здесь опции, я бы скорее попытался решить эту проблему с памятью, улучшив реализацию. Конкретные идеи, которые у нас есть для этого: 1) сделать маску необязательной, чтобы она могла быть Ничего из того, что нет недостающих данных (я думаю, это не должно быть слишком сложно) 2) исследовать использование битовой маски вместо маски логического массива (это вероятно, сложнее, поскольку в Python нет стандартной реализации этого, поэтому потребуется некоторый настраиваемый код).

Обратите внимание, что типы, допускающие значение NULL, в любом случае все еще являются экспериментальными (есть несколько операций, которые еще не работают, есть вещи, которые работают медленнее, ..), поэтому я думаю, что эта опция на начальном этапе будет в основном для того, чтобы позволить легко экспериментировать , попробуйте. И для такого случая использования, я думаю, более полезно преобразовать все возможные столбцы, а не решать проблему памяти, не преобразовывая все столбцы.

От @WillAyd

• Если в будущем мы добавим больше типов расширений, которые ориентированы не только на обработку NA, тогда нам придется добавить еще одно ключевое слово поверх этого для синтаксического анализа, что только усложнит задачу.

У меня была еще одна мысль по этому поводу. Из-за такого метода, как Series.shift() который создает записи с NA, я думаю, что любой новый тип расширения _always_ должен что-то делать с NA, и ИМХО, я думаю, мы бы хотели, чтобы они использовали pd.NA а не np.nan для представления "отсутствующего значения"

Это может означать, что такое ключевое слово, как use_missing_value_dtype может иметь смысл, хотя набирать его много.

И если мы действительно хотим подчеркнуть, что все дело в пропущенных значениях, использование pd.MV вместо pd.NA может помочь понять эту точку зрения, но это, вероятно, открывает целую банку червей.

@WillAyd относительно проблем с памятью маскированных массивов: https://github.com/pandas-dev/pandas/issues/30435 о том, чтобы сделать маску необязательной, и https://github.com/pandas-dev/pandas/issues / 31293 об исследовании битовых массивов для маски.

ключевое слово, например use_missing_value_dtype может иметь смысл

Поскольку np.nan в float dtype также используется как «пропущенное значение», я не уверен, что это менее двусмысленно, чем use_nullable_dtype (учитывая аргумент против use_nullable_dtype что есть другие типы dtypes, которые также "обнуляемый" без использования pd.NA).

as_NA_dtypes (поддерживающие pd.NA)

Это совершенно ясно!
Для меня недостатком этого является то, что я лично считаю, что это звучит менее хорошо, когда я использую его в качестве общей терминологии, чтобы говорить об этом (например, «типы NA» в тексте прозы).

Другой вариант - convert_dtypes=True/False . Я не думаю, что из названия очень ясно, что он будет делать, но это то, что мы получили для имени метода в https://github.com/pandas-dev/pandas/pull/30929

ключевое слово, например use_missing_value_dtype может иметь смысл

Поскольку np.nan в float dtype также используется как «пропущенное значение», я не уверен, что это менее двусмысленно, чем use_nullable_dtype (учитывая аргумент против use_nullable_dtype что есть другие типы dtypes, которые также "обнуляемый" без использования pd.NA).

as_NA_dtypes (поддерживающие pd.NA)

Это совершенно ясно!
Для меня недостатком этого является то, что я лично считаю, что это звучит менее хорошо, когда я использую его в качестве общей терминологии, чтобы говорить об этом (например, «типы NA» в тексте прозы).

Мы могли бы объединить эти две идеи, то есть as_missing_value_NA_dtypes , и вы говорите "отсутствующие значения NA dtypes" в текстах прозы, чтобы обозначать dtypes, которые представляют отсутствующие значения, используя pd.NA

Другой вариант - convert_dtypes=True/False . Я не думаю, что из названия очень ясно, что он будет делать, но это то, что мы получили для имени метода в # 30929

Как автор вышеизложенного, я бы проголосовал _против_ этого в контексте ввода-вывода, потому что convert_dtypes также имеет поведение inherit_objects , поэтому теперь у нас есть разные значения convert_dtypes в два разных контекста.

и вы говорите "отсутствующие значения NA dtypes" в текстах прозы, чтобы обозначить dtypes, которые представляют отсутствующие значения, используя pd.NA

Для меня это нормально, если это компромисс, с которым может смириться большинство людей. В этом случае мы должны обновить разделы документа «Целочисленный тип данных, допускающий значение NULL», на что-то вроде «Целочисленный тип данных с отсутствующим значением NA» или .. (хотя для заголовка это немного длинновато)

Но лично я бы просто предложил: давайте определим "nullable" как "dtype, который использует NA" в контексте pandas docs / dtypes в pandas . Это термин, который мы до сих пор не использовали ни для чего другого (в противном случае мы не используем его, когда говорим об отсутствующих значениях, все вхождения этого слова в документации относятся к новым типам данных)

Есть ли еще отзывы о моем предложении в комментарии чуть выше (https://github.com/pandas-dev/pandas/issues/29752#issuecomment-579112054) об использовании "nullable dtype" в контексте документации pandas как значение "dtype, который использует NA в качестве индикатора отсутствующего значения"?

Копия @ pandas-dev / pandas-core

имеет смысл, но тогда может возникнуть путаница с isnull, который считает np.NaN, pd.NaT, None и т. д. нулевыми.

isnull, который считает np.NaN, pd.NaT, None и т. д. нулевыми.

И у нас есть функция isna которая также считает все эти отсутствующие в дополнение к NA ... Так что да, никакая единая терминология не будет идеальной с учетом всего исторического багажа.
Мы можем обновить строку документации isnull чтобы четко указать, что это точный псевдоним isna и не обрабатывает «типы, допускающие значение NULL».

Дружественный пинг здесь. Если я не слышу возражений, я буду считать, что это нормально, если использовать термин «типы, допускающие значение NULL» как для «dtype, который использует NA в качестве индикатора отсутствующего значения» (в документации, docstring, потенциально ключевые слова xref # 31242)

nullable_dtypes не очень хорош

рассмотрел бы: return_dtypes = 'classic' или 'modern'

значение этого ключевого слова по умолчанию - «современное»? а это просто для совместимости?
в противном случае нам пришлось бы отказаться от этого, чтобы изменить, что кажется проблемой

значение этого ключевого слова по умолчанию - «современное»? а это просто для совместимости?
в противном случае нам пришлось бы отказаться от этого, чтобы изменить, что кажется проблемой

Начальный момент состоит в том, что людям легче выбрать опробовать новые типы dtypes (аналогично методу convert_dtypes , но в качестве опции для читателей, так как это может избежать лишнего преобразования).
Итак, нет, изначально это ключевое слово не будет по умолчанию использовать типы dtypes, допускающие значение NULL / современные (аналогично тому, как мы не планируем делать целочисленный тип dtype, допускающий значение NULL, по умолчанию int dtype в pandas 1.x)

Я не обязательно против термина «современный», но лично я считаю его менее описательным / более двусмысленным (или субъективным) как «допускающий значение NULL».
Например, является ли наш категориальный тип «современным» типом?

Я не обязательно против термина «современный», но лично я считаю его менее описательным / более двусмысленным (или субъективным) как «допускающий значение NULL».

Я согласен с Джорисом здесь. Классика / модерн также означает, что если в следующем году у нас будет еще лучшая идея, мы должны использовать слово «постмодерн».

Я не обязательно против термина «современный», но лично я считаю его менее описательным / более двусмысленным (или субъективным) как «допускающий значение NULL».

Я согласен с Джорисом здесь. Классика / модерн также означает, что если в следующем году у нас будет еще лучшая идея, мы должны использовать слово «постмодерн».

Я согласен с тем, что использование слова «современный» создает проблемы в будущем, даже если у нас нет лучшей идеи. Потому что, скажем, через 5 лет все останется по-прежнему. Тогда «модерну» 5 лет. Звучит странно.

Здесь есть две проблемы:

1. Какую фразу использовать при написании прозы для описания типов, поддерживающих pd.NA
2. Что использовать в качестве ключевого слова аргумента

Предложение @jorisvandenbossche состоит в том, чтобы решить эту проблему с помощью:

1. "nullable dtype" означает "pandas dtype, поддерживающий pd.NA "
2. Использование аргумента ключевого слова use_nullable_dtypes

Вот еще одна возможность:

1. "pandas dtype с поддержкой pd.NA "
2. Ключевое слово use_pd_NA_dtypes

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

+1 за определение «nullabe» как «dtypes с использованием NA в качестве индикатора отсутствующего значения».

Поскольку мы используем "nullable" уже в "nullable integer" или "nullable boolean" dtypes, и я полагаю, мы хотим продолжать использовать этот термин в этом контексте, я бы предпочел "nullable" чем "dtypes, поддерживающие pd.NA " .
Эти два случая, конечно, не являются двусмысленными, поскольку раньше они не могли хранить NA / NaN, а в будущем у нас могут быть более неоднозначные случаи, такие как числа с плавающей запятой. Но если мы используем "nullable", мы можем использовать его последовательно для всех типов dtypes, которые поддерживают NA, а не только для тех, которые раньше не поддерживали NaN.

Теперь, конечно, даже если мы решим использовать термин «обнуляемый» в качестве термина, мы все равно будем добавлять фразу «типы, поддерживающие pd.NA » многократно во многих местах документов / строк документов, чтобы установить эту взаимосвязь. .

Я все еще не являюсь поклонником nullable_dtypes . Действительно ли нам нужно обрабатывать StringArray и IntegerArray одновременно с помощью одного и того же ключевого слова? Интересно, не проясняет ли это разделение немного

Что касается первого, мне интересно, должны ли мы просто сделать это, т.е. ключевое слово не переключает поведение. То, что раньше было объектом dtype из подпрограмм ввода-вывода, в определенный момент заменяется строкой dtype.

Кажется менее агрессивным, чем изменение целого числа -> с плавающей запятой, которое, возможно, заслуживает специального ключевого слова

Интересно, стоит ли нам просто это сделать [о возврате строки dtype вместо объекта dtype]

"string" dtype не имеет обратной совместимости с объектом dtype, поэтому на данный момент (кроме экспериментального) это не значение по умолчанию. Однако в какой-то момент мы действительно захотим это изменить. Но я думаю, что это требует специального обсуждения.

Интересно, не проясняет ли это разделение немного

Это не только IntegerArray vs StringArray. В настоящее время это также уже BooleanArray (поэтому простое ключевое слово для целых чисел не покрывает это). И в будущем я надеюсь, что будут добавлены другие типы dtype, такие как float dtype с NA (https://github.com/pandas-dev/pandas/issues/32265), ...
Итак, да, для целых значений, допускающих значение NULL, мы могли бы добавить конкретное ключевое слово, но для меня речь идет о включении всех новых типов, использующих NA, и продолжать добавлять новые ключевые слова для каждого из них не кажется приемлемым?

является альтернативой глобальной опции конфигурации и полностью избегает добавления ключевых слов.

если пользователь просто хочет использовать новые типы для одного вызова чтения ввода-вывода, можно использовать синтаксис with pd.option_context(...): (или pd.read_excel('filename.excel').as_nullable_types() ).

Возможное именование вариантов может иметь вид иерархии use_pandas_2.0_api , use_experimental_dtypes , use_StringDType . где use_experimental_dtypes включает use_StringDType а use_pandas_2.0_api включает use_experimental_dtypes

и мы начали бы реализовывать ожидаемое поведение pandas 2.0 прямо сейчас. (и эти параметры будут удалены в 2.0rc)

без добавления ключевых слов мы также могли бы начать добавлять это, чтобы сказать конструктор DataFrame, без изменения api.

является альтернативой глобальной опции конфигурации и полностью избегает добавления ключевых слов.

Глобальная конфигурация, безусловно, интересна, и то, что время от времени предлагалось как способ подписаться на новые типы dtypes / другой способ попробовать это.
Лично я думаю, что имеет смысл также использовать его в качестве ключевых слов (параметр "локальный"), потому что параметр конфигурации работает глобально (и, например, также влияет на все библиотеки, которые вы используете), и в зависимости от вашей ситуации один или другой может работать лучше.

В любом случае, также для глобальной опции конфигурации нам нужно согласовать имя;) (что в идеале согласовано)

или pd.read_excel ('filename.excel'). as_nullable_types ()

Такой as_nullable_types() уже существует, это convert_dtypes() (на самом деле сначала он назывался as_nullable_dtypes , но переименован как компромисс).
Одна из причин, по которой в дополнение к этому методу все еще используется ключевое слово, состоит в том, чтобы избежать двойных преобразований (например, сначала преобразовать целые числа в числа с плавающей запятой в считывателе, а затем вывести и преобразовать числа с плавающей запятой обратно в целые числа в convert_dtypes ).

мы также могли бы начать добавлять это, чтобы сказать конструктор DataFrame,

Я думаю, что действительно было бы хорошим местом для добавления такого ключевого слова.

Потенциальная проблема с использованием «pandas 2.0» в любом названии заключается в том, что прямо сейчас нет никаких гарантий, что это будет фактически по умолчанию в pandas 2.0 .. (это будет зависеть от того, когда произойдет pandas 2.0, насколько мы добьемся прогресса в улучшении типы, допускающие значение NULL, и т. д.)

Одна из причин иметь ключевое слово в дополнение к этому методу - избегать двойных преобразований (например, сначала преобразовать целые числа в числа с плавающей запятой в читателе, а затем вывести и преобразовать числа с плавающей запятой обратно в целые числа в convert_dtypes ).

Другая причина заключается в том, что заставить «пустые типы dtypes» работать в разных читателях может быть реализовано в разное время для разных читателей. Например, возможно, сначала выполняется read_csv() , но затем заставить его работать в read_excel() , read_sql() происходит позже. Таким образом, аргумент ключевого слова может существовать не для всех читателей. Насколько я помню, когда я пытался понять это, использование обнуляемых типов dtypes должно было быть инструментировано отдельно для каждого читателя, но я мог ошибаться в этом.

Очередная попытка прийти к консенсусу или компромиссу здесь.

Итак, для терминологии + схемы именования ключевых слов или опций основное предложение:

• Терминология: "nullable dtype" означает "pandas dtype, поддерживающий pd.NA"
• Ключевое слово / название параметра: use_nullable_dtypes=True/False
  
  
  
  • Это явно говорит о том, что это приводит к типам, допускающим значение NULL, которые используют pd.NA в качестве индикатора отсутствующего значения.
  
  

При прокрутке цепочки упоминались следующие альтернативы именам ключевых слов:

• use_extension_dtypes
  
  
  
  • Проблема с этим заключается в том, что ключевое слово не для dtypes "extension" вообще, а только для dtypes расширений, которые используют pd.NA качестве индикатора отсутствующего значения (dtypes, допускающие значение NULL). Например, категориальный, datetimetz и т. Д. Являются типами расширений, но не являются предметом этого ключевого слова.
  
  
• use_modern_dtypes=True/False или return_dtypes=‘classic’/‘modern’
  
  
  
  • «современный» не очень наглядный, а также зависит от времени (через несколько лет что-то еще может стать новейшим «современным» способом)
  
  
• na_float_cast
  
  
  
  • Только о том, что целое число не преобразуется в float, поэтому это не общее имя для всех типов dtypes, допускающих значение NULL.
  
  
• use_pandas_2.0_api
  
  
  
  • Это зависит от того, действительно ли эти типы dtypes становятся значениями по умолчанию в pandas 2.0, чего мы пока не можем гарантировать.
  
  
• use_missing_value_dtype
  
  
  
  • pd.NA - не единственное "отсутствующее значение", np.nan (для float64) и pd.NaT также все еще пропущены. Так что ИМО это не менее неоднозначно, чем use_nullable_dtype
  
  
• use_experimental_dtypes
  
  
  
  • Это жизнеспособная альтернатива для меня, но IMO также менее ясна / описательна в том, что она делает.
  
  
• use_NA_dtypes (или use.pd_NA_dtypes или use_missing_value_NA_dtypes )
  
  
  
  • Это можно использовать вместе с «pandas dtypes, поддерживающими pd.NA» в документации.
  
  

Я думаю, что жизнеспособными альтернативами являются только два последних пункта. И для меня один из этих двух подходит, если это компромисс, с которым может смириться большинство людей. Но я также считаю, что «dtypes, допускающие значение NULL» строго лучше: мы уже используем этот термин в документации, когда говорим о целочисленных и логических типах dtypes, допускающих значение NULL (и мы не использовали «nullable» ранее для обозначения чего-либо еще).

Я знаю, что термин «допускающий значение NULL» не идеален (например, являются ли наши текущие (основанные на numpy) столбцы с плавающей запятой, которые используют NaN в качестве индикатора отсутствующего значения, «допускающие значение NULL» или нет?), Но нам все еще нужен какой-то термин для обозначения dtypes, которые используйте pd.NA качестве индикатора пропущенного значения, и до сих пор я думаю, что "nullable" - лучшее, что у нас есть.

@jorisvandenbossche Отличное резюме. Мне нравятся use_nullable_dtypes и use_NA_dtypes (Примечание: в начале вашего сообщения выше вы использовали единственное число с use_nullable_dtype а не множественное число use_nullable_dtypes , поэтому мы также нужно выяснить, хотим ли мы единственного или множественного числа).

Мне интересно, должны ли мы создать опрос и позволить людям голосовать. И, как я сказал во время телеконференции, если вам не нравится какое-либо из предложений, сделанных до сих пор, вы должны предложить что-то еще, чтобы добавить в список, а не просто сказать «Мне не нравится ни одно из них»: - )

вы использовали единственное число с use_nullable_dtype вместо множественного use_nullable_dtypes, поэтому нам также нужно выяснить, хотим ли мы единственное или множественное число).

Ах, это тип (сейчас редактируется). Поскольку существует несколько типов dtypes, допускающих значение NULL, я думаю, нам следует использовать просто множественное число.

+1 для определения "типов, допускающих значение NULL" и ключевого слова use_nullable_dtypes .

Я бы предпочел use_na_dtypes для ясности

отправлено из моего Айфона

15 мая 2020 года в 9:39 Том Аугспургер [email protected] написал:

+1 для определения "типов, допускающих значение NULL" и ключевого слова use_nullable_dtypes.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

@WillAyd означает ли это также, что вы предпочли бы заменить все использование «пустых типов dtypes» в нашей документации на «dtypes, которые используют NA как отсутствующее значение» или «dtypes, поддерживающие pd.NA» или тому подобное? (например, на https://pandas.pydata.org/docs/user_guide/boolean.html)

Еще один дружеский пинг ..

@WillAyd Насколько сильны ваши предпочтения? Может быть, немного сложно дать точный ответ, но это означает: я все еще предпочитаю use_nullable_dtypes , и, поскольку большинство участвующих голосов согласны с этим, я все равно хотел бы пойти с use_nullable_dtypes если ваши предпочтения не слишком сильны.
(и поскольку я настаиваю на этом, мне немного сложно принять окончательное решение ...)

Что касается самого ключевого слова, я тоже относительно хорошо отношусь к use_NA_dtypes . Но для запуска текста в документации и т. Д. Я предпочел бы говорить о «типах, допускающих значение NULL» (на самом деле, как мы уже делаем прямо сейчас). И если мы сделаем это в документации, я думаю, мы также должны согласовываться с ключевым словом.

Я по-прежнему считаю, что use_NA_dtypes будет лучше, если мы добавим типы floatNA. Я не буду вдаваться в подробности

@jreback тоже не согласен с этим, так что стоит посмотреть, где он стоит, и двигаться дальше

@WillAyd, в таком случае, не могли бы вы ответить на мой вопрос о том, что вы будете делать с документами?

Конечно, я думаю, что упоминание о них как о типах NA более понятно, чем о типах с нулевым значением.

пришли сюда, хорошо с use_nullable_dtypes это соответствует нашим текущим описаниям документов.

Считаем ли мы это блокировщиком 1.1? Если да, то кто-нибудь хочет над этим поработать?

я думаю, мы объединим текущее предложение

Кто-нибудь (@ Dr-Irv, @jorisvandenbossche) может с этим поработать? Кажется, это стоит сделать для 1.1, если это займет всего несколько дней.

@TomAugspurger Для меня это не займет несколько дней, потому что я думаю, что изменения должны быть сделаны на довольно низком уровне читателей, и мне нужно будет выяснить, как работает этот код. Простое решение - использовать convert_dtypes внутри различных считывателей после текущих операций чтения, но это было бы неэффективно с точки зрения памяти.

Меня отправили сюда из номера №35576. (Хотя https://github.com/pandas-dev/pandas/issues/29752#issuecomment-613077209, возможно, предполагает, что это действительно должно быть отдельное обсуждение?)

Лично меня больше всего волнует "выключение" в этом предстоящем выпуске "Modern Pandas" - это откат к объекту dtype. (Потому что это делает вещи на порядки медленнее, и это довольно легко сделать «за вас» за кулисами). Да, некоторые из них вызваны необходимостью pd.NA для numpy dtype, который его не поддерживает, но не все случаи из этого.

В качестве очень конкретного варианта использования я бы хотел, чтобы read_csv() всегда использовал StringDtype вместо объекта dtype. (Это немного упростило бы мою жизнь.) Но мне неясно, применимо ли к этому обозначение типа "обнуляемый тип". На мой взгляд, объект dtype, безусловно, допускает значение NULL, не так ли? Так что лично я бы не подумал, что use_nullable_dtypes=True влияет на это. Мысли?

@ chrish42 Посмотрите на этот комментарий: https://github.com/pandas-dev/pandas/issues/29752#issuecomment -629294120

Определение «обнуляемого dtype» - это «pandas dtype, поддерживающий pd.NA». Это включает StringDtype но не object , поэтому, как только это будет реализовано, вы сможете получить StringDtype в результате pd.read_csv()

@ Dr-Irv Круто, спасибо. Мне было не сразу понятно. По крайней мере, в отличие от других случаев, нет причин, по которым объект не может поддерживать pd.NA , верно ?. И для меня основным недостатком имени use_nullable_types является то, что даже люди, которым не нужны типы, допускающие значение NULL, выиграют от установки его в True. (Ну, почти каждый выиграет от установки значения True.) Но я полагаю, что здесь нет идеального имени, и хорошая документация должна будет сделать остальную работу и донести до пользователей то, что имя не передает.

В любом случае, действительно с нетерпением жду того дня, когда автоматические преобразования в объект (потому что строки) и в float (потому что NA) уйдут в прошлое. Так что всем спасибо!

нет причин, по которым объект не может поддерживать pd.NA, верно ?.

Я бы не рекомендовал этого. Необходимо написать алгоритмы для явной обработки NA, поскольку это очень необычно.

нет причин, по которым объект не может поддерживать pd.NA, верно ?.

Я бы не рекомендовал этого. Необходимо написать алгоритмы для явной обработки NA, поскольку это очень необычно.

см. # 32931 для получения информации о специальном выпуске

@ chrish42, если кто-то заинтересован только в получении нового string dtype (чтобы избежать объекта dtype), то, безусловно, верно, что use_nullable_dtypes=True не совсем очевиден (я думаю, что это также одна из причин для долгого обсуждения выше).

Но мы, конечно, хотим, чтобы ключевое слово включало все типы dty, допускающие значение NULL, например, также допускающие значение NULL int и bool, допускающие значение NULL, чтобы избежать преобразования в float и т. Д. И тогда имя имеет больше смысла. В таком случае добавление еще одного ключевого слова для получения string dtype, вероятно, будет уже слишком.