Pandas: ENH: Izinkan memilih ikut serta ke tipe d baru pada rutinitas I/O melalui kata kunci ke rutinitas I/O

@jorisvandenbossche apakah ini mungkin untuk 1.0? Preferensi awal saya adalah menambahkan ini di masa mendatang (sebagai opsi dalam 1.1 katakan)

Ini tentu saja tidak rilis kritis, jadi mari kita hapus dari tonggak sejarah.

Jadi, apakah Anda punya ide bagaimana kami ingin mengatasi ini? Saya pikir juga konstruktor (misalnya DataFrame(..) ) dapat menggunakan opsi serupa.

Opsi seperti use_new_dtypes=True/False secara konsisten di seluruh fungsi yang membuat kerangka data/seri?
Atau nama yang lebih baik, karena "baru" tidak terlalu deskriptif. use_nullable_dtypes mungkin tidak sepenuhnya mencakup string, karena string tersebut sudah dapat dibatalkan sebelumnya.

Saya ingin berargumen bahwa jika Anda ingin membuat orang menggunakan dtypes baru, dan terutama pd.NA , maka ini menjadi sangat penting, karena IMHO, sebagian besar nilai yang hilang diperkenalkan ketika orang membaca data. Jadi jika Anda tidak mengubah rutinitas I/O, pd.NA tidak mungkin digunakan.

Untuk nama, mungkin use_extension_dtypes ??

Apa yang saya tidak suka tentang use_extension_dtypes kedengarannya sebagai ekstensi ke panda, yang di sini tidak demikian. Harapannya adalah bahwa pada titik tertentu itu adalah dtypes default.
(Saya tahu, semuanya disebut Extension.., tapi tetap saja).

Bagaimana dengan use_distinct_dtypes ?

@jorisvandenbossche Saya mulai melihat ini, dan jika kami melakukannya untuk setiap pembaca, itu mungkin akan menjadi banyak pekerjaan karena semua implementasi pembaca yang berbeda. Ini usulan lain. Bagaimana jika kita membuat metode DataFrame.as_nullable_types() yang akan mengambil DataFrame dan mengonversi kolom apa pun yang bisa menjadi tipe nullable. Kemudian jika Anda menggunakan pembaca apa pun, yang tidak menggunakan tipe baru, Anda dapat mengonversi seluruh DataFrame dalam satu baris, sehingga Anda dapat memiliki df = pd.read_csv('filename.csv').as_nullable_types() atau df = pd.read_excel('filename.excel').as_nullable_types() , dll Aturannya bisa terlihat seperti ini:

1. Jika dtype adalah objek, konversikan ke string. Jika gagal, biarkan saja.
2. Jika dtype adalah float, coba konversi ke boolean. Jika gagal, coba konversi ke Int64. Jika itu gagal, biarkan saja.

Tujuan saya di sini adalah untuk memudahkan orang menggunakan StringDType , Int64DType , dan BooleanDType . Jika kita tidak melakukan sesuatu seperti ini, saya rasa tipe-tipe itu tidak akan dijalankan, karena nilai-nilai yang hilang biasanya ditemukan saat membaca data, dan sulit untuk menentukan tipe d untuk setiap kolom saat membaca data dengan banyak kolom.

jika kami melakukannya untuk setiap pembaca, itu mungkin akan menjadi banyak pekerjaan karena semua implementasi pembaca yang berbeda

Jika kita ingin memiliki metode yang efisien, kita mungkin harus berakhir dengan implementasi khusus pembaca, saya pikir. Tapi, bukan berarti tentu saja semua pembaca harus mendukungnya secara asli, kita bisa memulainya dengan yang penting dan meminta orang lain mengonversinya setelah membaca. Misalnya, saya berencana untuk mengerjakan pembaca parket yang secara langsung memberi Anda bilangan bulat yang dapat dibatalkan (yang menghindari salinan dan perjalanan pulang pergi yang tidak dibutuhkan untuk mengapung). Semua untuk mengatakan: Saya pikir masih berguna untuk memilikinya sebagai opsi pembaca juga dalam beberapa kasus.

Namun demikian, metode/fungsi pembantu untuk mengubah kerangka data yang ada menjadi kerangka data baru menggunakan tipe yang dapat dibatalkan terdengar seperti ide yang bagus, bagaimanapun juga akan berguna.
Secara konseptual, ini agak mirip dengan DataFrame.infer_objects ("Mencoba menyimpulkan tipe d yang lebih baik untuk kolom objek.", kecuali di sini kita ingin menyimpulkan tipe d yang lebih baik untuk semua kolom)

@jorisvandenbossche Saya akan mengerjakan metode pembantu, karena saya pikir itu harus di 1.0, dan kemudian kita bisa mencari cara untuk mengubah berbagai pembaca (dan dalam urutan yang mana) untuk versi yang lebih baru.

Saya memasang PR yang mengimplementasikan opsi use_nullable_dtypes untuk read_parquet secara khusus: https://github.com/pandas-dev/pandas/pull/31242

Dalam PR menambahkan opsi ke read_parquet , kami mengadakan diskusi yang semakin umum tentang opsi semacam itu di IO, dan lebih umum tentang apa yang diharapkan dari opsi semacam itu (tidak hanya namanya), jadi memindahkannya ke sini.

@jreback dan @WillAyd menyebutkan bahwa mereka lebih suka use_extension_dtypes daripada use_nullable_dtypes , yang saya jawab:

Bagi saya, alasan utama untuk tidak menggunakan use_extension_dtypes adalah: 1) opsi ini tidak memicu untuk mengembalikan tipe ekstensi secara umum. Misalnya, itu tidak memicu untuk mengembalikan kategoris atau datetimetz (seperti yang sudah dikembalikan secara default oleh pyarrow), dan itu tidak memicu untuk mengembalikan periode atau interval (yang dapat dikembalikan berdasarkan metadata yang disimpan dalam file parket / ekstensi pyarrow jenis); dalam kedua kasus, jenis ekstensi akan dikembalikan bahkan dengan use_extension_dtypes=False . Sebaliknya, saya menemukan use_nullable_dtypes lebih jelas dalam mengkomunikasikan maksud*.
Selain itu, dan secara lebih semantik, jenis "ekstensi" dapat memberikan gambaran tentang jenis ekstensi "eksternal" (tetapi ini adalah masalah secara umum dengan istilah tersebut, jadi tidak terlalu relevan di sini).

*Saya pikir kita akan memerlukan beberapa terminologi untuk menunjukkan "tipe d yang menggunakan pd.NA sebagai indikator nilai yang hilang" . Juga untuk komunikasi kita (dan ketika berdiskusi) tentang hal itu, untuk dokumen, dll, akan lebih baik untuk memiliki istilah yang dapat kita gunakan secara konsisten. Saya pikir "nullable dtypes" adalah opsi untuk ini (kami sudah menggunakan "nullable integer dtype" untuk sementara waktu di dokumen), meskipun tentu saja tidak ideal, karena sebenarnya dtypes lain juga "nullable" (float, objek, datetime) , hanya dengan cara yang berbeda.
Mungkin diskusi yang lebih umum ini dapat membantu kami menemukan nama kata kunci yang cocok setelahnya.

balasan dari @WillAyd

Tentu seperti beberapa argumen balasan cepat:

• Semantik tidak jelas bagi pengguna akhir; Saya pikir sebagian besar menganggap np.float sebagai nullable yang tidak akan terpengaruh
• Beberapa argumen untuk kejelasannya khusus untuk parket, tetapi saya pikir menjadi lebih ambigu jika kita menggunakan kembali kata kunci yang sama untuk parser lain (yang saya harap kita akan melakukannya)
• Jika kami menambahkan lebih banyak jenis ekstensi di masa mendatang yang tidak hanya berfokus pada penanganan NA, maka kami harus menambahkan kata kunci lain di atasnya untuk diuraikan, yang hanya membuat segalanya lebih rumit

Poin ketiga mungkin yang menurut saya paling menjadi masalah

_balasan dari @WillAyd_

• Jika kami menambahkan lebih banyak jenis ekstensi di masa mendatang yang tidak hanya berfokus pada penanganan NA, maka kami harus menambahkan kata kunci lain di atasnya untuk diuraikan, yang hanya membuat segalanya lebih rumit

Poin ketiga mungkin yang menurut saya paling menjadi masalah

Saya setuju ini adalah argumen yang meyakinkan untuk tidak menggunakan as_nullable_dtypes . Berikut adalah beberapa ide:

• as_NA_dtypes (yang mendukung pd.NA )
• as_modern_dtypes (karena apa pun yang ingin kami dukung adalah yang paling modern)
• as_endorsed_dtypes (baru kita bisa menentukan mana yang endorse/recomended)

Semoga itu merangsang diskusi!

Terima kasih @WillAyd untuk argumen itu. Dari situ, sepertinya kita masih perlu mendiskusikan/mengklarifikasi apa sebenarnya tujuan yang ingin kita capai dengan opsi seperti itu

Semantik tidak jelas bagi pengguna akhir; Saya pikir sebagian besar menganggap np.float sebagai nullable yang tidak akan terpengaruh

Ya, itulah yang saya sebutkan tentang "nullable" tidak ideal. Tapi itu masalah umum untuk berbicara tentang tipe-d itu. Dan seperti yang disebutkan di atas, saya pikir kita perlu menemukan beberapa istilah untuk itu.
Jika kami dengan jelas mendefinisikan apa yang kami maksud dengan "nullable dtype" dalam dokumen dan menggunakannya secara konsisten di seluruh dokumen untuk tujuan itu, saya pikir istilah seperti itu dapat berfungsi (IMO, setidaknya lebih baik daripada tidak ada istilah yang konsisten).
Juga, di beberapa titik kita mungkin ingin memiliki float dtype yang menggunakan pd.NA sebagai nilai yang hilang. Begitu juga maka kita membutuhkan istilah untuk membedakannya dari float dtype "klasik" ("nullable float dtype" ?)

Beberapa argumen untuk kejelasannya khusus untuk parket, tetapi saya pikir menjadi lebih ambigu jika kita menggunakan kembali kata kunci yang sama untuk parser lain (yang saya harap kita akan melakukannya)

Parket adalah salah satu format yang memiliki informasi tipe paling banyak, sehingga perbedaan antara tipe ekstensi pada umumnya dan tipe nullable pada spesifik memang paling relevan di sana. Saat membaca misalnya csv Anda memang tidak bisa mendapatkan kategoris. Tapi itu tidak sepenuhnya terbatas pada parket. read_feather dan read_orc juga didasarkan pada pyarrow, jadi miliki dukungan jenis yang sama. Anda bisa mendapatkan categoricals dari read_stata dan read_spss , Anda bisa mendapatkan datetimetz dari read_sql dan (mungkin?) read_excel

Jika kami menambahkan lebih banyak jenis ekstensi di masa mendatang yang tidak hanya berfokus pada penanganan NA, maka kami harus menambahkan kata kunci lain di atasnya untuk diuraikan, yang hanya membuat segalanya lebih rumit

Ya, jika jenis ekstensi baru tersebut tidak menggunakan pd.NA sebagai indikator nilai yang hilang, mereka sengaja tidak termasuk dalam kata kunci ini. Masalah ini di sini benar-benar khusus tentang tipe-d yang menggunakan pd.NA, karena mereka memiliki perilaku yang berbeda untuk operasi yang melibatkan nilai-nilai yang hilang.
Sekarang, saya pribadi berpendapat bahwa kita tidak boleh menambahkan dtypes ekstensi baru yang tidak menggunakan pd.NA , tapi itu diskusi lain. Juga sulit untuk membahas kasus hipotetis seperti itu; satu contoh konkret yang muncul adalah sesuatu seperti struct/json: itu mungkin tidak dapat disimpan dalam format file biasa seperti csv (dan juga, kita mungkin dapat menggunakan pd.NA sebagai nilai yang hilang di sana).

Jika kami menambahkan lebih banyak jenis ekstensi di masa mendatang yang tidak hanya berfokus pada penanganan NA, maka kami harus menambahkan kata kunci lain di atasnya untuk diuraikan, yang hanya membuat segalanya lebih rumit

Poin ketiga mungkin yang menurut saya paling menjadi masalah

Saya setuju ini adalah argumen yang meyakinkan untuk tidak menggunakan as_nullable_dtypes.

Untuk menyoroti satu poin dari posting panjang saya di atas yang menjawab aspek ini: IMO, jika tipe baru seperti itu tidak menggunakan pd.NA, itu tidak boleh termasuk dalam kata kunci ini. Jadi jika kita melakukan itu (tentu saja dapat diperdebatkan), maka nama apa pun yang kita gunakan (seperti use_NA_dtypes ) akan memiliki masalah yang sama persis.

Arah yang sedikit berbeda tetapi bagaimana dengan sesuatu seperti na_float_cast=True sebagai default? Saya pikir lebih jelas tentang niat dan juga tidak memaksa untuk menggunakan ekstensi dtype kecuali nilai NA benar-benar terdeteksi, yang dapat membantu menghemat memori

Arah yang sedikit berbeda tetapi bagaimana dengan sesuatu seperti nan_float_cast=True sebagai default? Saya pikir lebih jelas tentang niat dan juga tidak memaksa untuk menggunakan ekstensi dtype kecuali nilai NA benar-benar terdeteksi, yang dapat membantu menghemat memori

Itu tergantung pada perilaku opsi. Saat ini, saya pikir tujuannya adalah untuk menggunakan misalnya nullable integer dtype untuk semua kolom integer, tidak hanya kolom integer yang memiliki nilai yang hilang dan jika tidak akan dicor ke float. (Juga, untuk boolean, mereka dicor ke objek sekarang jika ada pelampung)

Memang benar bahwa tidak melakukannya untuk semua kolom dapat menghemat memori, tetapi secara pribadi saya lebih suka melakukannya untuk semua kolom: 1) Anda mendapatkan hasil yang konsisten tergantung pada jenis "logis" kolom Anda, bukan pada adanya nilai yang hilang ( misalnya jika hanya membaca di bagian file, ini sudah bisa berbeda 2) nilai yang hilang juga dapat diperkenalkan setelah membaca (misalnya pengindeksan ulang, penggabungan, ..) dan kemudian memiliki integer dtype nullable memastikan tidak dilemparkan ke mengapung kemudian, bahkan jika data asli tidak memiliki nans

Itu tergantung pada perilaku opsi. Saat ini, saya pikir tujuannya adalah untuk menggunakan misalnya nullable integer dtype untuk semua kolom integer, tidak hanya kolom integer yang memiliki nilai yang hilang dan jika tidak akan dicor ke float. (Juga, untuk boolean, mereka dicor ke objek sekarang jika ada pelampung)

Ya saya setuju - klarifikasi tentang maksud itu pasti mendorong ini.

Saya tidak berpikir itu layak menambahkan topeng kecuali diperlukan - itu pasti dapat memiliki dampak memori yang tidak sepele. Jika matematika sederhana saya tepat untuk 10 juta baris kali 10 kolom
blok nilai integer yang menambahkan topeng akan membutuhkan setidaknya 100 MB lebih banyak di memori

Saya pikir tidak ada gunanya menambahkan topeng kecuali diperlukan

Tetapi daripada membatasi kolom yang akan dikonversi ke dtypes bertopeng/nullable dengan opsi yang sedang dibahas di sini, saya lebih suka mencoba menyelesaikan masalah memori ini dengan meningkatkan implementasi. Ide konkret yang kami miliki untuk ini: 1) membuat topeng opsional, sehingga bisa Tidak ada data yang hilang (saya pikir ini seharusnya tidak terlalu sulit untuk dilakukan) 2) selidiki menggunakan bitmask alih-alih topeng array boolean (ini mungkin lebih sulit, karena tidak ada implementasi standar ini di Python, sehingga akan memerlukan beberapa kode khusus).

Perhatikan bahwa dtypes yang dapat dibatalkan masih bersifat eksperimental (ada beberapa operasi yang belum berfungsi, ada hal-hal yang lebih lambat, ..), jadi saya pikir opsi ini pada fase awal terutama untuk memungkinkan eksperimen dengan mudah , cobalah. Dan untuk kasus penggunaan seperti itu, saya pikir lebih berguna untuk mengonversi semua kolom yang mungkin daripada mengatasi masalah memori dengan tidak mengonversi semua kolom.

Dari @WillAyd

• Jika kami menambahkan lebih banyak jenis ekstensi di masa mendatang yang tidak hanya berfokus pada penanganan NA, maka kami harus menambahkan kata kunci lain di atasnya untuk diuraikan, yang hanya membuat segalanya lebih rumit

Saya punya pemikiran lain tentang ini. Karena metode seperti Series.shift() yang membuat entri dengan NA di dalamnya, saya pikir semua jenis ekstensi baru _always_ perlu melakukan sesuatu tentang NA, dan IMHO, saya pikir kami ingin mereka menggunakan pd.NA dan bukan np.nan untuk mewakili "nilai yang hilang"

Yang mungkin berarti bahwa kata kunci seperti use_missing_value_dtype mungkin masuk akal, meskipun banyak yang harus diketik.

Dan jika kita benar-benar ingin menekankan bahwa ini semua tentang nilai yang hilang, menggunakan pd.MV alih-alih pd.NA mungkin membantu menyampaikan maksud itu, tetapi itu mungkin membuka kaleng worm lainnya.

@WillAyd mengenai masalah memori array bertopeng: ada https://github.com/pandas-dev/pandas/issues/30435 tentang membuat topeng opsional dan https://github.com/pandas-dev/pandas/issues /31293 tentang menjelajahi bitarray untuk topeng.

kata kunci seperti use_missing_value_dtype mungkin masuk akal

Karena np.nan di float dtype juga digunakan sebagai "nilai yang hilang", saya tidak yakin ini kurang ambigu dari use_nullable_dtype (mengingat argumen terhadap use_nullable_dtype bahwa ada dtypes lain yang juga "nullable" tanpa menggunakan pd.NA).

as_NA_dtypes (yang mendukung pd.NA)

Ini cukup eksplisit!
Bagi saya, kelemahan yang satu ini adalah bahwa saya pribadi menemukan bahwa kedengarannya kurang baik ketika menggunakannya sebagai terminologi umum untuk berbicara tentang ini (seperti "tipe NA" dalam teks prosa).

Pilihan lain adalah convert_dtypes=True/False . Saya tidak berpikir itu sangat jelas dari nama apa yang akan dilakukannya, tetapi itulah yang kami dapatkan untuk nama metode di https://github.com/pandas-dev/pandas/pull/30929

kata kunci seperti use_missing_value_dtype mungkin masuk akal

Karena np.nan di float dtype juga digunakan sebagai "nilai yang hilang", saya tidak yakin ini kurang ambigu dari use_nullable_dtype (mengingat argumen terhadap use_nullable_dtype bahwa ada dtypes lain yang juga "nullable" tanpa menggunakan pd.NA).

as_NA_dtypes (yang mendukung pd.NA)

Ini cukup eksplisit!
Bagi saya, kelemahan yang satu ini adalah bahwa saya pribadi menemukan bahwa kedengarannya kurang baik ketika menggunakannya sebagai terminologi umum untuk berbicara tentang ini (seperti "tipe NA" dalam teks prosa).

Kita bisa menggabungkan dua ide, yaitu, as_missing_value_NA_dtypes , dan Anda mengatakan "nilai yang hilang NA dtypes" dalam teks prosa berarti dtypes yang mewakili nilai yang hilang menggunakan pd.NA

Pilihan lain adalah convert_dtypes=True/False . Saya tidak berpikir itu sangat jelas dari namanya apa yang akan dilakukannya, tetapi itulah yang kami dapatkan untuk nama metode di #30929

Sebagai penulis di atas, saya akan memilih _melawan_ bahwa dalam konteks I/O karena convert_dtypes juga memiliki perilaku inherit_objects , jadi sekarang kita memiliki arti yang berbeda dari convert_dtypes di dua konteks yang berbeda.

dan Anda mengatakan "nilai yang hilang NA dtypes" dalam teks prosa berarti dtypes yang mewakili nilai yang hilang menggunakan pd.NA

Bagi saya tidak apa-apa jika itu adalah kompromi yang dapat diterima oleh kebanyakan orang. Dalam hal ini kita harus memperbarui bagian dokumen pada "Tipe data integer Nullable" menjadi sesuatu seperti "Tipe data integer dengan nilai NA yang hilang" atau .. (itu agak lama untuk sebuah judul)

Tetapi secara pribadi, saya hanya akan mengusulkan: mari kita definisikan "nullable" sebagai "dtype yang menggunakan NA" dalam konteks pandas docs / dtypes di pandas . Ini adalah istilah yang tidak kami gunakan untuk hal lain hingga sekarang (kami tidak menggunakannya ketika berbicara tentang nilai yang hilang, semua kemunculan dalam dokumen dari Word ini adalah tentang dtypes baru)

Apakah ada lebih banyak umpan balik tentang proposal saya di komentar tepat di atas ( https://github.com/pandas-dev/pandas/issues/29752#issuecomment-579112054 ) untuk menggunakan "nullable dtype" dalam konteks dokumentasi pandas sebagai makna "dtype yang menggunakan NA sebagai indikator nilai yang hilang"?

cc @pandas-dev/pandas-core

masuk akal tetapi kemudian dapat menyebabkan kebingungan dengan isnull yang menganggap np.NaN, pd.NaT, None dll sebagai nol.

isnull yang menganggap np.NaN, pd.NaT, None dll sebagai null.

Dan kami memiliki fungsi isna yang juga menganggap semua yang hilang selain NA ... Jadi ya, tidak ada terminologi tunggal yang ideal mengingat semua bagasi historis.
Kami dapat memperbarui docstring dari isnull untuk menunjukkan dengan jelas bahwa itu adalah alias yang tepat dari isna , dan tidak menangani "nullable dtypes" yang berbeda.

Ping ramah di sini. Jika saya tidak mendengar keberatan, saya akan menganggapnya baik-baik saja dengan menggunakan istilah "nullable dtypes" seperti untuk "dtype yang menggunakan NA sebagai indikator nilai yang hilang" (dalam dokumentasi, docstring, berpotensi kata kunci xref #31242)

nullable_dtypes tidak bagus

akan mempertimbangkan: return_dtypes='classic' atau 'modern'

apakah maksud kata kunci ini default ke 'modern'? dan itu hanya untuk kompatibilitas?
jika tidak, kita harus mencela ini untuk mengubah yang tampaknya merepotkan

apakah maksud kata kunci ini default ke 'modern'? dan itu hanya untuk kompatibilitas?
jika tidak, kita harus mencela ini untuk mengubah yang tampaknya merepotkan

Poin awalnya adalah memudahkan orang untuk ikut serta mencoba tipe baru (mirip dengan metode convert_dtypes , tetapi sebagai opsi bagi pembaca, karena hal itu dapat menghindari konversi tambahan).
Jadi tidak, awalnya kata kunci ini tidak default untuk menggunakan nullable / modern dtypes (sama seperti kami tidak berencana untuk membuat nullable integer dtype int dtype default di pandas 1.x)

Saya tidak selalu menentang istilah "modern", tetapi saya pribadi menganggapnya kurang deskriptif / lebih ambigu (atau subjektif) sebagai "nullable".
Misalnya, apakah dtype kategoris kami adalah dtype "modern"?

Saya tidak selalu menentang istilah "modern", tetapi saya pribadi menganggapnya kurang deskriptif / lebih ambigu (atau subjektif) sebagai "nullable".

Saya setuju dengan Joris di sini. klasik/modern juga berarti bahwa jika kita memiliki ide yang lebih baik tahun depan kita harus menggunakan "post-modern"

Saya tidak selalu menentang istilah "modern", tetapi saya pribadi menganggapnya kurang deskriptif / lebih ambigu (atau subjektif) sebagai "nullable".

Saya setuju dengan Joris di sini. klasik/modern juga berarti bahwa jika kita memiliki ide yang lebih baik tahun depan kita harus menggunakan "post-modern"

Saya setuju bahwa menggunakan "modern" menciptakan masalah di masa depan, bahkan jika kita tidak memiliki ide yang lebih baik. Karena katakanlah hal-hal tetap sama 5 tahun dari sekarang. Maka "modern" adalah 5 tahun. Kedengarannya aneh.

Ada dua masalah yang berperan di sini:

1. Frasa apa yang digunakan saat menulis prosa untuk mendeskripsikan jenis yang mendukung pd.NA
2. Apa yang harus digunakan sebagai kata kunci argumen

Proposal di atas meja oleh @jorisvandenbossche adalah untuk menyelesaikan ini melalui:

1. "nullable dtype" berarti "a pandas dtype yang mendukung pd.NA "
2. Menggunakan argumen kata kunci use_nullable_dtypes

Berikut adalah kemungkinan lain:

1. "pandas dtype mendukung pd.NA "
2. Kata kunci use_pd_NA_dtypes

Saya baik-baik saja dengan salah satu di atas dan hanya ingin merangsang diskusi.

+1 untuk mendefinisikan "nullabe" sebagai "dtypes menggunakan NA sebagai indikator nilai yang hilang".

Karena kita sudah menggunakan "nullable" dalam tipe "nullable integer" atau "nullable boolean", dan saya kira kita ingin tetap menggunakan istilah itu dalam konteks itu, saya lebih memilih "nullable" daripada "dtypes yang mendukung pd.NA " .
Kedua kasus tersebut tentu saja tidak ambigu, karena sebelumnya tidak dapat menyimpan NA/NaN, sementara di masa depan kita mungkin memiliki kasus yang lebih ambigu seperti float. Tetapi jika kita menggunakan "nullable", kita dapat menggunakannya secara konsisten untuk semua tipe yang mendukung NA, tidak hanya yang tidak mendukung NaN sebelumnya.

Sekarang, tentu saja, bahkan jika kita memutuskan untuk menggunakan "nullable" sebagai istilah, kita masih akan menambahkan frasa "dtypes yang mendukung pd.NA " berulang kali di banyak tempat di docs/docstrings, tepatnya untuk membangun hubungan ini .

Saya masih juga bukan penggemar nullable_dtypes . Apakah kita benar-benar perlu menangani StringArray dan IntegerArray secara bersamaan melalui kata kunci yang sama di sini? Saya ingin tahu apakah memisahkan itu tidak sedikit menjelaskan

Untuk yang pertama saya bertanya-tanya apakah kita harus melakukannya saja yaitu kata kunci tidak mengubah perilaku. Apa yang sebelumnya merupakan objek dtype dari rutinitas IO diganti dengan string dtype pada titik tertentu

Tampaknya kurang invasif daripada integer -> float change yang mungkin pantas mendapatkan kata kunci khusus

Saya ingin tahu apakah kita harus melakukannya [tentang mengembalikan string dtype alih-alih objek dtype]

"string" dtype tidak kompatibel dengan objek dtype, jadi itulah alasannya untuk saat ini (selain eksperimental), ini bukan default. Kami memang ingin mengubah ini di beberapa titik, meskipun. Tapi saya pikir itu memerlukan diskusi khusus.

Saya ingin tahu apakah memisahkan itu tidak sedikit menjelaskan

Ini bukan hanya IntegerArray vs StringArray. Saat ini, itu juga sudah BooleanArray (jadi hanya kata kunci untuk int tidak akan mencakup ini). Dan di masa depan, saya berharap dtypes lain akan ditambahkan, seperti float dtype dengan NAs (https://github.com/pandas-dev/pandas/issues/32265), ...
Jadi ya, untuk nullable ints kita bisa menambahkan kata kunci tertentu, tapi bagi saya ini tentang mengaktifkan semua tipe baru yang menggunakan NA, dan terus menambahkan kata kunci baru untuk masing-masing sepertinya tidak berkelanjutan?

adalah opsi konfigurasi global sebagai alternatif, dan hindari menambahkan kata kunci sepenuhnya.

jika pengguna hanya ingin menggunakan tipe baru untuk satu panggilan baca IO, dapat menggunakan sintaks with pd.option_context(...): (atau pd.read_excel('filename.excel').as_nullable_types() ).

penamaan opsi potensial dapat berupa use_pandas_2.0_api , use_experimental_dtypes , use_StringDType semacam hierarki. di mana use_experimental_dtypes termasuk use_StringDType dan use_pandas_2.0_api termasuk use_experimental_dtypes

dan kami akan mulai menerapkan perilaku pandas 2.0 yang diantisipasi sekarang. (dan opsi ini akan dihapus di 2.0rc)

tanpa penambahan kata kunci, kita juga bisa mulai menambahkan ini untuk mengatakan konstruktor DataFrame, tanpa mengubah api.

adalah opsi konfigurasi global sebagai alternatif, dan hindari menambahkan kata kunci sepenuhnya.

Konfigurasi global tentu saja menarik, dan sesuatu yang telah disarankan dari waktu ke waktu sebagai cara untuk memilih dtypes baru / cara lain untuk mencobanya.
Secara pribadi, saya pikir masuk akal untuk juga memilikinya sebagai kata kunci (opsi "lokal"), karena opsi konfigurasi berfungsi secara global (dan misalnya juga memengaruhi semua perpustakaan yang Anda gunakan), dan tergantung pada situasi Anda, satu atau yang lain mungkin bekerja lebih baik.

Bagaimanapun, juga untuk opsi konfigurasi global kita harus menyetujui nama ;) (yang idealnya konsisten)

atau pd.read_excel('filename.excel').as_nullable_types()

as_nullable_types() semacam itu sudah ada, itu adalah convert_dtypes() (sebenarnya disebut as_nullable_dtypes dulu, tetapi diganti namanya sebagai kompromi).
Salah satu alasan untuk tetap memiliki kata kunci selain metode ini adalah untuk menghindari konversi ganda (misalnya pertama-tama mengonversi bilangan bulat ke float di pembaca, lalu menyimpulkan dan mengubah float kembali ke bilangan bulat di convert_dtypes ).

kita juga bisa mulai menambahkan ini untuk mengatakan konstruktor DataFrame,

Saya pikir apa yang memang akan menjadi tempat yang baik untuk menambahkan kata kunci seperti itu.

Masalah potensial dengan menggunakan "pandas 2.0" dalam penamaan apa pun, adalah bahwa saat ini tidak ada jaminan ini akan menjadi default di pandas 2.0 .. (itu akan tergantung pada kapan pandas 2.0 terjadi, seberapa banyak kemajuan yang kami buat untuk peningkatan dtypes yang dapat dibatalkan, dll)

Salah satu alasan untuk tetap memiliki kata kunci selain metode ini adalah untuk menghindari konversi ganda (misalnya pertama-tama mengonversi bilangan bulat ke float di pembaca, lalu menyimpulkan dan mengubah float kembali ke bilangan bulat di convert_dtypes ).

Alasan lain adalah bahwa membuat "nullable dtypes" berfungsi di pembaca yang berbeda mungkin diimplementasikan pada waktu yang berbeda untuk pembaca yang berbeda. Misalnya, mungkin read_csv() diselesaikan terlebih dahulu, tetapi kemudian membuatnya bekerja di read_excel() , read_sql() terjadi kemudian. Jadi argumen kata kunci mungkin tidak ada untuk semua pembaca. Jika saya ingat ketika saya mencoba untuk mencari tahu ini, penggunaan dtypes nullable harus diinstrumentasikan secara terpisah untuk setiap pembaca, tapi saya bisa salah tentang itu.

Upaya lain untuk mencoba mencapai konsensus atau kompromi di sini.

Jadi untuk terminologi + skema penamaan untuk kata kunci atau opsi, proposal utamanya adalah:

• Terminologi: "nullable dtype" berarti "a pandas dtype yang mendukung pd.NA"
• Kata kunci/nama opsi: use_nullable_dtypes=True/False
  
  
  
  • Ini adalah tentang eksplisit bahwa hasil dalam dtypes nullable yang menggunakan pd.NA sebagai indikator nilai yang hilang.
  
  

Menggulir utas, alternatif berikut untuk nama kata kunci telah disebutkan:

• use_extension_dtypes
  
  
  
  • Masalah dengan hal ini adalah bahwa kata kunci adalah bukan untuk "ekstensi" dtypes pada umumnya, tapi hanya untuk perpanjangan dtypes yang menggunakan pd.NA hilang indikator nilai (dtypes nullable). Misalnya kategoris, datetimetz, dll adalah tipe ekstensi, tetapi bukan subjek dari kata kunci ini.
  
  
• use_modern_dtypes=True/False atau return_dtypes=‘classic’/‘modern’
  
  
  
  • "modern" tidak terlalu deskriptif, dan juga bergantung pada waktu (dalam beberapa tahun sesuatu yang lain mungkin merupakan cara "modern" terbaru)
  
  
• na_float_cast
  
  
  
  • Hanya tentang integer yang tidak dilemparkan ke float, jadi bukan nama umum untuk semua tipe d yang dapat dibatalkan
  
  
• use_pandas_2.0_api
  
  
  
  • Ini tergantung pada tipe d yang benar-benar menjadi default di pandas 2.0, sesuatu yang belum dapat kami jamin saat ini
  
  
• use_missing_value_dtype
  
  
  
  • pd.NA bukan satu-satunya "nilai yang hilang", np.nan (untuk float64) dan pd.NaT juga masih memiliki nilai yang hilang. Jadi IMO ini tidak kalah ambigunya dengan use_nullable_dtype
  
  
• use_experimental_dtypes
  
  
  
  • Ini adalah alternatif yang layak bagi saya, tetapi IMO juga kurang jelas/deskriptif dalam fungsinya
  
  
• use_NA_dtypes (atau use.pd_NA_dtypes atau use_missing_value_NA_dtypes )
  
  
  
  • Ini dapat digunakan bersama dengan "pandas dtypes yang mendukung pd.NA" dalam dokumentasi.
  
  

Saya pikir hanya dua poin terakhir yang merupakan alternatif yang layak. Dan bagi saya, salah satu dari keduanya baik-baik saja, jika itu adalah kompromi yang dapat diterima oleh kebanyakan orang. Tapi saya juga berpikir bahwa "nullable dtypes" benar-benar lebih baik: kita sudah menggunakan istilah ini di dokumen ketika berbicara tentang nullable integer dan boolean dtypes (dan kita tidak menggunakan "nullable" sebelumnya untuk menunjukkan hal lain).

Saya tahu istilah "nullable" tidak sempurna (misalnya, apakah kolom float kami saat ini (berbasis numpy) yang menggunakan NaN sebagai indikator nilai yang hilang "nullable" atau tidak?), tetapi kami masih memerlukan beberapa istilah untuk merujuk ke dtypes itu gunakan pd.NA sebagai indikator nilai yang hilang, dan sampai sekarang, saya pikir "nullable" masih yang terbaik yang kami miliki.

@jorisvandenbossche Ringkasan yang bagus. Saya suka use_nullable_dtypes dan use_NA_dtypes (Catatan: Pada awal posting Anda di atas, Anda menggunakan bentuk tunggal dengan use_nullable_dtype daripada jamak use_nullable_dtypes , jadi kami juga harus mencari tahu apakah kita ingin tunggal atau jamak juga).

Saya ingin tahu apakah kita harus membuat polling dan membiarkan orang memilih. Dan seperti yang saya katakan di telepon, jika Anda tidak menyukai saran yang dibuat sejauh ini, Anda harus mengusulkan sesuatu yang lain untuk ditambahkan ke daftar, daripada hanya mengatakan "Saya tidak suka salah satu dari mereka" :- )

Anda menggunakan bentuk tunggal dengan use_nullable_dtype daripada bentuk jamak use_nullable_dtypes, jadi kita juga harus mencari tahu apakah kita ingin bentuk tunggal atau jamak juga).

Ah, itu tipe (diedit sekarang). Karena ada beberapa dtype yang dapat dibatalkan, saya pikir kita harus menggunakan jamak saja.

+1 untuk definisi "nullable dtypes" dan kata kunci use_nullable_dtypes .

Saya lebih suka use_na_dtypes untuk ketegasan

dikirim dari iPhone saya

Pada 15 Mei 2020, pukul 09:39, Tom Augspurger [email protected] menulis:

+1 untuk definisi "nullable dtypes" dan kata kunci use_nullable_dtypes.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

@WillAyd apakah itu juga berarti Anda lebih suka mengganti semua penggunaan "dtypes yang dapat dibatalkan" dalam dokumentasi kami menjadi "dtypes yang menggunakan NA sebagai nilai yang hilang" atau "dtypes yang mendukung pd.NA" atau serupa? (misalnya di https://pandas.pydata.org/docs/user_guide/boolean.html)

Ping ramah lagi..

@WillAyd Seberapa kuat preferensi Anda? Mungkin agak sulit untuk menjawab dengan tepat, tetapi artinya: Saya juga masih memiliki preferensi untuk use_nullable_dtypes , dan karena ada mayoritas suara yang berpartisipasi OK dengan itu, saya masih ingin menggunakan use_nullable_dtypes jika preferensi Anda tidak terlalu kuat.
(dan karena saya yang mendorongnya, agak sulit bagi saya untuk membuat keputusan akhir ...)

Untuk kata kunci itu sendiri, sebenarnya saya juga cukup setuju dengan use_NA_dtypes . Tetapi untuk menjalankan teks dalam dokumentasi dll, saya lebih suka berbicara tentang "nullable dtypes" (seperti yang sudah kita lakukan sekarang, sebenarnya). Dan jika kita melakukannya di dokumen, saya pikir kita harus konsisten dengan kata kuncinya juga.

Saya terus berpikir bahwa use_NA_dtypes lebih baik khususnya setelah kita menambahkan tipe floatNA. Saya tidak akan menjelaskan intinya

@jreback juga tidak setuju dengan ini, jadi lihat di mana dia berdiri dan pergi dari sana

@WillAyd dalam hal ini, dapatkah Anda menjawab pertanyaan saya tentang apa yang akan Anda lakukan dengan dokumen?

Tentu saya pikir menyebut mereka sebagai tipe NA lebih jelas daripada tipe d Nullable

telah datang ke sini, ok dengan use_nullable_dtypes ini cocok dengan deskripsi dokumen kami saat ini.

Apakah kami menganggap ini sebagai pemblokir untuk 1.1? Kalau ada, ada yang mau kerja?

saya pikir kami menggabungkan proposal saat ini

Adakah (@Dr-Irv, @jorisvandenbossche) yang bisa mengerjakan ini? Ini sepertinya layak dilakukan untuk 1.1 jika hanya membutuhkan beberapa hari.

@TomAugspurger Bagi saya, itu tidak akan memakan waktu beberapa hari, karena saya pikir perubahan harus dilakukan pada tingkat yang cukup rendah di pembaca, dan saya harus mencari tahu cara kerja kode itu. Solusi mudahnya adalah menggunakan convert_dtypes di dalam berbagai pembaca setelah operasi baca saat ini, tetapi itu tidak efisien dari sudut pandang memori.

Saya dikirim ke sini dari edisi #35576. (Meskipun https://github.com/pandas-dev/pandas/issues/29752#issuecomment-613077209 mungkin menyarankan bahwa ini perlu menjadi diskusi terpisah?)

Secara pribadi, hal yang paling saya pedulikan tentang "mematikan" dalam edisi "Panda Modern" yang akan datang ini adalah mundurnya ke objek dtype. (Karena itu membuat urutan besarnya lebih lambat, dan cukup mudah untuk itu terjadi "untuk Anda" di belakang layar). Ya, beberapa di antaranya disebabkan oleh kebutuhan pd.NA untuk tipe numpy yang tidak mendukungnya, tetapi tidak semua kasus berasal dari itu.

Sebagai kasus penggunaan yang sangat konkret, saya ingin cara read_csv() untuk selalu menggunakan StringDtype alih-alih objek dtype. (Itu akan sedikit menyederhanakan hidup saya.) Tetapi tidak jelas bagi saya penunjukan "nullable dtypes" berlaku untuk itu. Dalam pikiran saya, objek dtype tentu saja dapat dibatalkan, bukan? Jadi, saya tidak akan menganggap use_nullable_dtypes=True mempengaruhi itu, secara pribadi. Pikiran?

@chrish42 Lihat komentar ini: https://github.com/pandas-dev/pandas/issues/29752#issuecomment -629294120

Definisi dari "nullable dtype" adalah "a pandas dtype yang mendukung pd.NA". Itu termasuk StringDtype tetapi tidak object , jadi setelah ini diterapkan, Anda akan bisa mendapatkan StringDtype sebagai hasil dari pd.read_csv()

@Dr-Irv Keren, terima kasih. Itu tidak segera jelas bagi saya. Setidaknya, tidak seperti waktu lain, tidak ada alasan mengapa objek tidak dapat mendukung pd.NA , bukan?. Dan bagi saya, kelemahan utama dengan nama use_nullable_types adalah bahwa bahkan orang-orang yang tidak memerlukan tipe nullable akan mendapat manfaat dari menyetelnya ke True. (Yah, hampir semua orang akan mendapat manfaat dari menyetelnya ke True.) Tapi saya rasa tidak ada nama yang sempurna di sini, dan dokumentasi yang baik harus melakukan sisa pekerjaan dan menyampaikan kepada pengguna apa yang tidak disampaikan oleh nama tersebut.

Bagaimanapun, sangat menantikan hari ketika konversi otomatis ke objek (karena string) dan float (karena NA) adalah sesuatu dari masa lalu. Jadi terima kasih semuanya!

tidak ada alasan mengapa objek tidak dapat mendukung pd.NA, kan?.

Saya akan merekomendasikan menentangnya. Algoritma perlu ditulis untuk menangani NA secara eksplisit karena sangat tidak biasa.

tidak ada alasan mengapa objek tidak dapat mendukung pd.NA, kan?.

Saya akan merekomendasikan menentangnya. Algoritma perlu ditulis untuk menangani NA secara eksplisit karena sangat tidak biasa.

lihat #32931 untuk edisi khusus

@chrish42 jika seseorang hanya tertarik untuk mendapatkan string dtype baru (untuk menghindari objek dtype), memang benar bahwa use_nullable_dtypes=True tidak terlalu jelas (saya pikir itu juga salah satu alasannya untuk diskusi panjang di atas).

Tapi, kita tentu ingin kata kunci untuk memilih semua dtypes nullable, jadi misalnya juga nullable int dan nullable bool untuk menghindari casting ke float dll Dan kemudian nama lebih masuk akal. Menambahkan kata kunci lain untuk mendapatkan string dtype mungkin terlalu banyak.