Pandas: API: .convert_objects tidak digunakan lagi, apakah kita ingin .convert diganti?

cc @bashtage
@jorisvandenbossche @shoyer @TomAugspurger @sinhrks

Sudah ada _convert yang bisa dipromosikan.

Pada Jumat, 2 Okt 2015, 10:16 Jeff Reback [email protected] menulis:

cc @bashtage https://github.com/bashtage
@jorisvandenbossche https://github.com/jorisvandenbossche @shoyer
https://github.com/shoyer @TomAugspurger
https://github.com/TomAugspurger @sinhrks https://github.com/sinhrks

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/pydata/pandas/issues/11221#issuecomment -145033282.

Keuntungan dari convert yang dirancang dengan baik adalah ia bekerja pada DataFrames. Semua to_* hanya untuk tipe 1-d.

@bashtage oh saya setuju.

Masalahnya adalah dengan coerce , pada dasarnya Anda harus tidak memaksa secara otomatis sebagian sehingga menyerahkan hal-hal yang ambigu kepada pengguna (melalui penggunaan 1-d dari pd.to_* ). Tapi dengan asumsi kita melakukan itu maka ya, Anda bisa membuatnya bekerja.

Saya baru saja memikirkan kasus di mana saya mengimpor data yang seharusnya numerik ke dalam DF, tetapi memiliki beberapa karakter campuran, dan saya hanya ingin angka atau NaN. Jenis konversi inilah yang akhirnya saya inginkan ketika saya mulai melihat convert_objects ketika saya terkejut bahwa meminta coerce dari semua string tidak memaksanya ke NaN.

tetapi masalahnya adalah campuran boolean/nan yang ambigu (jadi mungkin hanya perlu 'menangani' itu)

Beberapa komentar/pengamatan:

• Saya sebenarnya suka convert_objects lebih dari convert , karena lebih jelas mengatakan apa fungsinya: coba ubah objek dtyped kolom ke builtin dtype (convert agak umum).
• Jika kami memutuskan bahwa kami menyukai objek konversi saat ini _fungsionalitas_, saya tidak benar-benar melihat alasan untuk tidak menggunakan convert_objects untuk converts . Saya pikir secara teknis mungkin untuk menghentikan _keywords_ lama (dan bukan fungsinya) demi kata kunci baru. (sebenarnya pendekatan asli dalam PR yang dikembalikan).
• Saya pikir fungsionalitas convert_objects berguna (seperti yang sudah dinyatakan di atas: bahwa Anda dapat melakukan sesuatu seperti to_datetime/to_numeric/.. pada kerangka data). Menggunakan fungsi to_.. pada setiap seri yang terpisah akan selalu menjadi solusi yang lebih disukai untuk kode yang kuat, tetapi selama convert_objects didefinisikan dengan sangat jelas (sekarang ada beberapa inkonsistensi yang aneh), saya pikir itu berguna untuk memiliki ini. Akan sangat bagus jika ini bisa diimplementasikan dalam hal metode to_.. .
  Sedikit disederhanakan dalam kode semu:

def convert_objects(self, numeric=False, datetime=False, timedelta=False, coerce=False): for each column: if numeric: pd.to_numeric(self, coerce=coerce) elif datetime: pd.to_datetime(self, coerce=coerce) elif timedelta: pd.to_timedelta(self, coerce=coerce)

• Tapi, masalah utama dengan ini adalah: alasan convert_objects berguna sekarang, justru karena ia memiliki 'aturan' tambahan yang tidak dimiliki metode to_.. : _only convert the column if setidaknya ada satu nilai yang dapat dikonversi_.
  Inilah alasan mengapa sesuatu seperti ini berfungsi:

```
Dalam [2]: df = pd.DataFrame({'int_str':['1', '2'], 'real_str':['a', 'b']})

Dalam [3]: df.convert_objects(convert_numeric=True)
Keluar[3]:
int_str real_str
0 1
1 2 b

Dalam [4]: ​​df.convert_objects(convert_numeric=True).dtypes
Keluar[4]:
int_str int64
objek real_str
dtype: objek
```

dan tidak memberikan:

Out[3]: int_str real_str 0 1 NaN 1 2 NaN

yang tidak akan terlalu berguna (walaupun mungkin lebih dapat diprediksi). Fakta bahwa tidak selalu dipaksa untuk NaNs dianggap sebagai bug, yang @bashtage melakukan PR (dan untuk to_numeric , juga logis bahwa ia mengembalikan NaNs). Tapi ini membuat convert_objects juga kurang berguna (jadi akhirnya dikembalikan).
Jadi saya pikir dalam kasus ini, kita harus menyimpang dari perilaku to_..

Mungkin ini bisa menjadi parameter tambahan untuk convert/convert_objects : apakah akan memaksa kolom yang tidak dapat dikonversi ke NaN atau tidak (artinya: kolom yang setidaknya tidak ada satu elemen yang dapat dikonversi dan akan mengarah ke kolom NaN penuh) . @bashtage maka Anda dapat memiliki perilaku yang Anda inginkan, tetapi metode ini masih dapat digunakan untuk kerangka data karena tidak semua kolom harus dianggap sebagai numerik.

ok jadi pertanyaannya adalah haruskah kita menghentikan convert_objects thrn?

Saya benar-benar berpikir bahwa konversi adalah nama yang jauh lebih baik dan kami tentu saja dapat menambahkan opsi yang Anda jelaskan untuk membuatnya lebih bermanfaat

convert_objects sepertinya fitur API yang buruk karena memiliki ketergantungan jalur ini di mana itu

mencoba mengonversi ke tipe a
mencoba mengonversi ke tipe b jika a gagal, tetapi tidak jika a berhasil
mencoba mengonversi ke tipe c adalah a dan b gagal, tetapi tidak jika keduanya berhasil

Desain yang lebih baik hanya akan mengonversi satu jenis yang menghilangkan ambiguitas apa pun jika beberapa data dapat dikonversi menjadi lebih dari satu jenis. untuk to_* semacam sampai di sana, dengan peringatan bahwa mereka mengoperasikan kolom demi kolom.

umur panjang convert_objects!

mungkin yang kami butuhkan di dokumen adalah beberapa contoh yang menunjukkan:

df.apply(pd.to_numeric) dan semacamnya (yang secara efektif / lebih aman) menggantikan .convert_objects

Halo semua,

Saat ini saya menggunakan convert_objects di banyak kode saya dan saya pikir fungsi ini sangat berguna ketika mengimpor kumpulan data yang mungkin berbeda setiap hari dalam hal komposisi kolom. Apakah benar-benar perlu untuk mencela atau ada kesempatan untuk tetap hidup?

Terimakasih banyak,
umberto

.convert_objects secara inheren ambigu dan ini sudah usang beberapa versi yang lalu. lihat dokumen di sini untuk cara eksplisit melakukan konversi objek.

Saya setuju dengan @jreback - convert_objects penuh keajaiban dan sulit untuk menebak perilaku yang tidak konsisten di seluruh target konversi yang berbeda (misalnya angka tidak memaksa jika semua bukan angka bahkan jika disuruh memaksa).

Sebuah penebak yang dirancang dengan baik dengan aturan yang jelas dan sederhana dan tidak ada pilihan untuk memaksa dapat berguna, tetapi tidak sulit untuk menulis aturan Anda sendiri dengan seperangkat aturan favorit Anda.

FYI, opsi konversi semua (errors='coerce') dan abaikan (errors='ignore') di .to_numeric adalah masalah dalam file data yang berisi kolom string yang ingin Anda simpan dan kolom string yang sebenarnya adalah angka yang dinyatakan dalam notasi ilmiah (misalnya, 6.2e+15) yang memerlukan 'pemaksaan' untuk mengubah dari string ke float64.

File convert.py (usang) memiliki fungsi konversi lunak yang berguna yang memeriksa apakah konversi paksa menghasilkan semua NaN (seperti string yang ingin Anda simpan) dan kemudian menolak untuk mengonversi seluruh kolom.

Opsi kesalahan keempat, seperti 'soft-coerce,' akan menangkap nomor notasi ilmiah tanpa memaksa semua string ke NaN.

Saat ini, pekerjaan saya di sekitar adalah:

    for col in df.columns:   
        converted = pd.to_numeric(df[col],errors='coerce')  
        df[col] = converted if not pd.isnull(converted).all() else df[col]

Hal terbaik tentang convert_objects dari berbagai metode to_* adalah Anda tidak perlu mengetahui tipe data sebelumnya. Seperti yang dikatakan @usagliaschi , Anda mungkin memiliki data heterogen yang masuk dan ingin satu fungsi menanganinya. Ini persis situasi saya saat ini.

Apakah ada pengganti untuk fungsi yang akan cocok dengan fungsi ini, khususnya menyimpulkan tanggal/waktu?

xref https://github.com/pandas-dev/pandas/pull/15757#issuecomment -288090118

Saya pikir akan layak untuk mengekspos apa pun yang baru dari soft convert api 0,20 (saya belum melihatnya secara detail), merujuknya dalam pesan depr convert_objects, lalu tunda convert_objects ke versi berikutnya, jika memungkinkan.

Saya mengatakan ini karena saya tahu ada orang (misalnya, saya) yang telah mengabaikan pesan depr convert_objects dalam beberapa kasus, khususnya bekerja dengan data di mana Anda tidak perlu tahu kolomnya. Contoh nyata:

df = pd.read_html(source)[0]  # poorly formatted table, everything inferred to object
                              # exact columns can vary

df.columns = df.loc[0, :]
df = df.drop(0).dropna()

df = df.convert_objects()

Melihat ini lagi, saya menyadari df.apply(lambda x: pd.to_numeric(x, errors='ignore')) juga akan berfungsi dengan baik dalam kasus ini, tetapi itu tidak segera terlihat, dan saya tidak yakin kami telah melakukan cukup pegangan (karena tidak ada istilah yang lebih baik) untuk membantu transisi orang.

JIKA kita memutuskan untuk mengekspos 'soft convert objects', apakah kita ingin ini disebut .covert_objects() ? atau nama lain, mungkin .convert() ? (mis. alih-alih menghapus penghentian, kami hanya mengubahnya - yang mungkin lebih dalam memecah kembali-kompat).

xref #15550

jadi saya pikir resolusi untuk ini bisa:

• menambahkan .to_* ke Series (#15550)
• menambahkan .to_* ke DataFrame
• menambahkan opsi soft

maka cukup mudah untuk dilakukan:

df.to_numeric(errors='soft')

jika Anda benar- benar ingin .convert_object() .

df.to_datetime(errors='soft').to_timedelta(errors='soft').to_numeric(errors='soft')

Dan saya kira dapat menawarkan fitur kenyamanan untuk ini:

• df.to_converted()
• df.convert() (mungkin terlalu umum)
• df.convert_objects() (bangkit)
• df.to_just_figure_this_out()

Saya pikir fungsi konversi lunak yang paling berguna akan memiliki kemampuan untuk memesan aturan to_* , misalnya numerik-tanggal-waktu atau waktu-tanggal-numerik karena kadang-kadang ada data yang dapat ditafsirkan sebagai beberapa jenis. Setidaknya ini yang terjadi di convert_objects . Atau, seseorang hanya dapat memilih subset filter, seperti hanya mempertimbangkan tanggal numerik.

Saya setuju memperluas to_* untuk beroperasi dengan benar di DataFrames akan berguna.

Terima kasih @jreback - Saya suka menambahkan to_... ke DataFrame api, meskipun mungkin ada baiknya memisahkan kasus penggunaan. Pertimbangkan bingkai yang tidak berbentuk ini:

df = pd.DataFrame({'num_objects': [1, 2, 3], 'num_str': ['1', '2', '3']}, dtype=object)

df
Out[2]: 
  num_objects num_str
0           1       1
1           2       2
2           3       3

df.dtypes
Out[3]: 
num_objects    object
num_str        object
dtype: object

Perilaku default convert_objects adalah hanya menginterpretasikan ulang int python menjadi tipe int yang tepat, bukan membuang string. Ini adalah perilaku yang sangat saya rindukan untuk membunuh convert_objects , dan mencurigai orang lain juga.

df.convert_objects().dtypes
Out[4]: 
num_objects     int64
num_str        object
dtype: object

In [5]: df.apply(pd.to_numeric).dtypes
Out[5]: 
num_objects    int64
num_str        int64
dtype: object

Jadi apakah layak menambahkan convert_pyobjects (...tidak jatuh cinta dengan nama itu) hanya untuk kasus ini?
infer_python_types
convert_python_types
??

Saya pikir cukup mudah untuk menambahkan opsi soft ke errors untuk melakukan hal ini.

Apakah pd.Series(['1', '2', '3']).to_numeric(errors='soft') dilemparkan?

soft hanya akan kembali [3] (seperti coerce

Perbedaannya adalah [4] (Seri di dalamnya). Saya pikir soft akan kembali [5] dan coerce akan kembali [4]

In [3]: pd.to_numeric(pd.Series(['1', '2', '3']), errors='coerce')
Out[3]: 
0    1
1    2
2    3
dtype: int64

In [4]: pd.to_numeric(pd.Series(['1', '2', 'foo']), errors='coerce')
Out[4]: 
0    1.0
1    2.0
2    NaN
dtype: float64

In [5]: pd.to_numeric(pd.Series(['1', '2', 'foo']), errors='ignore')
Out[5]: 
0      1
1      2
2    foo
dtype: object

Terima kasih untuk contoh-contohnya.

Saya masih berpikir "hanya mengubah objek python tanpa kehilangan menjadi dtypes yang tepat" mungkin lebih baik sebagai operasi terpisah dari to_numeric ? Tidak akan ada cara untuk menghasilkan Out[4] dari contoh saya di atas?

Saya tidak berpikir bahwa mungkin untuk mengubah objek python tanpa kehilangan menjadi tipe d yang tepat secara umum didefinisikan dengan baik. Tentu saja ada objek yang tidak memiliki representasi asli lossless (mis. str->float).

Ambiguitas yang baru saja dijelaskan ini justru merupakan tantangan dalam menulis konverter yang berguna, benar dan tepat.

Haruskah rangkaian opsi konversi dan aturan yang akan digunakan dijelaskan sebelum menerapkannya? Saya pikir mereka harus atau kode akan default menjadi referensi set aturan (yang merupakan salah satu masalah dengan convert_objects ).

Untuk lebih jelasnya, yang saya maksud dengan konversi lossless adalah melakukan persis apa yang akan dilakukan pd.Series([<python objects]>) - mengonversi ke numpy dtype jika memungkinkan, jika tidak dibiarkan sebagai objek.

Saya pikir inti dari convert_objects dan penerus apa pun adalah untuk secara ketat melampaui apa yang akan dilakukan alat io secara otomatis. TKI, beberapa paksaan dari beberapa objek kadang-kadang sangat penting. convert_objects akan, misalnya, memaksa campuran string dan angka menjadi angka dan nol. Alat seperti read_csv sengaja tidak melakukan ini karena ini cukup arbitrer.

to_* cukup tepat dan melakukan apa yang Anda katakan kepada mereka, bahkan untuk non-objek. Sebagai contoh:

import pandas as pd
import datetime as dt
t = pd.Series([dt.datetime.now(), dt.datetime.now()])

pd.to_numeric(t)
Out[7]: 
0    1490739351272159000
1    1490739351272159000
dtype: int64

Saya akan berasumsi bahwa penerus convert_objects hanya akan mengonversi object dtype dan tidak akan berperilaku seperti ini.

Alasan saya tidak suka menambahkan fungsi .to_ sebagai metode pada DataFrame (atau setidaknya bukan sebagai solusi dalam diskusi ini), adalah karena IMO Anda biasanya tidak ingin menerapkan ini ke semua kolom dan/ atau tidak dengan cara yang sama (dan jika Anda menginginkan ini, Anda dapat dengan mudah melakukan pendekatan apply seperti yang dapat Anda lakukan sekarang).
Misalnya dengan DataFrame.to_datetime , saya berharap itu melakukan ini untuk semua kolom, yang berarti keduanya mengubah kolom numerik sebagai kolom string. Saya tidak berpikir ini biasanya yang Anda inginkan.

Jadi bagi saya salah satu alasan untuk memiliki metode convert_objects (terlepas dari detail perilaku yang tepat) adalah karena metode itu hanya akan mencoba mengonversi kolom yang diketik object sebenarnya.

ok jika kita menghidupkan kembali ini dengan tanda tangan baru. ini saat ini.

In [1]: DataFrame.convert_objects?
Signature: DataFrame.convert_objects(self, convert_dates=True, convert_numeric=False, convert_timedeltas=True, copy=True)
Docstring:
Deprecated.

Attempt to infer better dtype for object columns

Parameters
----------
convert_dates : boolean, default True
    If True, convert to date where possible. If 'coerce', force
    conversion, with unconvertible values becoming NaT.
convert_numeric : boolean, default False
    If True, attempt to coerce to numbers (including strings), with
    unconvertible values becoming NaN.
convert_timedeltas : boolean, default True
    If True, convert to timedelta where possible. If 'coerce', force
    conversion, with unconvertible values becoming NaT.
copy : boolean, default True
    If True, return a copy even if no copy is necessary (e.g. no
    conversion was done). Note: This is meant for internal use, and
    should not be confused with inplace.

IIRC @jorisvandenbossche menyarankan. (dengan modus).

DataFrame.convert_object(self, datetime=True, timedelta=True, numeric=False, copy=True)

Padahal jika semuanya berubah. Maka mungkin kita harus mengganti nama ini. (perhatikan .convert_object )

Maaf saya baru kembali ke sini, inilah proposal tentang bagaimana saya pikir ini bisa bekerja, terbuka untuk saran di bagian apa pun.

0.20.1 - tinggalkan convert_objects tetapi perbarui pesan depr dengan metode baru yang akan saya lalui
0.20.2 - hapus convert_objects

Pertama, untuk konversi yang hanya membuka kotak objek python, tambahkan metode baru infer_objects tanpa opsi. Ini pada dasarnya menerapkan kembali inferensi ctor kami pada kolom objek apa pun, dan jika sebuah kolom dapat di-unbox tanpa kehilangan ke tipe asli, lakukan, jika tidak biarkan tidak berubah. Berguna dalam skenario munging di mana inferensi asli gagal. Contoh:

df = pd.DataFrame({'a': ['a', 1, 2, 3],
                   'b': ['b', 2.0, 3.0, 4.1],
                   'c': ['c', datetime.datetime(2016, 1, 1), datetime.datetime(2016, 1, 2), 
                         datetime.datetime(2016, 1, 3)]})

df = df.iloc[1:]

In [194]: df
Out[194]: 
   a    b                    c
1  1    2  2016-01-01 00:00:00
2  2    3  2016-01-02 00:00:00
3  3  4.1  2016-01-03 00:00:00

In [195]: df.dtypes
Out[195]: 
a    object
b    object
c    object
dtype: object

# exactly what convert_objects does in this scenario today!
In [196]: df.infer_objects().dtypes
Out[196]: 
a             int64
b           float64
c    datetime64[ns]
dtype: object

Kedua, untuk semua konversi lainnya, tambahkan to_numeric , to_datetime , dan to_datetime ke DataFrame API, dengan tanda berikut. Pada dasarnya berfungsi seperti yang mereka lakukan hari ini, tetapi beberapa opsi pemilihan kolom kenyamanan. Tidak yakin dengan default di sini, dimulai dengan yang paling 'nyaman'

"""
DataFrame.to_...(self, errors='ignore', object_only=True, include=None, exclude=None)
Parameters
------------
errors: {'ignore', 'coerce', 'raise'}
   error mode passed to `pd.to_....`
object_only: boolean
    if True, only apply inference to object typed columns

include / exclude: column selection
"""

Contoh bingkai, dengan apa yang dibutuhkan saat ini:

df1 = pd.DataFrame({
    'date': pd.date_range('2014-01-01', periods=3),
    'date_unconverted': ['2014-01', '2015-01', '2016-01'],
    'number': [1, 2, 3],
    'number_unconverted': ['1', '2', '3']})


In [198]: df1
Out[198]: 
        date date_unconverted  number number_unconverted
0 2014-01-01          2014-01       1                  1
1 2014-01-02          2015-01       2                  2
2 2014-01-03          2016-01       3                  3

In [199]: df1.dtypes
Out[199]: 
date                  datetime64[ns]
date_unconverted              object
number                         int64
number_unconverted            object
dtype: object


In [202]: df1.convert_objects(convert_numeric=True, convert_dates='coerce').dtypes
C:\Users\chris.bartak\AppData\Local\Continuum\Anaconda3\lib\site-packages\ipykernel_launcher.py:1: FutureWarning: convert_objects is deprecated.  Use the data-type specific converters pd.to_datetime, pd.to_timedelta and pd.to_numeric.
  """Entry point for launching an IPython kernel.
Out[202]: 
date                  datetime64[ns]
date_unconverted      datetime64[ns]
number                         int64
number_unconverted             int64
dtype: object

Dengan api baru:

In [202]: df1.to_numeric().to_datetime()
Out[202]: 
date                  datetime64[ns]
date_unconverted      datetime64[ns]
number                         int64
number_unconverted             int64
dtype: object

Dan sejujurnya, saya pribadi tidak terlalu peduli dengan API kedua, penolakan saya atas penghentian convert_objects sepenuhnya didasarkan pada kurangnya sesuatu seperti infer_objects

Saya akan menggandakan infer_objects() selama aturannya jelas dan implementasinya sesuai dengan deskripsi. Kasus penggunaan penting lainnya adalah ketika seseorang berakhir dengan DF yang dialihkan dengan semua kolom objek, dan kemudian sesuatu seperti df = df.T.infer_types() akan menghasilkan

Saya pikir fungsi seperti to_numeric , dll. seharusnya tidak menggunakan metode pada kerangka data dan sebagai gantinya harus berdiri sendiri. Saya tidak berpikir mereka cukup sering digunakan untuk mencemari toDaftar.

Keren, ya semakin saya memikirkan semakin sedikit saya pikir menambahkan to_... ke api DataFrame adalah ide yang bagus. Dalam hal infer_objects impl pada dasarnya adalah sebagai berikut - berdasarkan maybe_convert_objects , yang umumnya tidak mengejutkan (menurut saya) perilaku:

In [251]: from pandas._libs.lib import maybe_convert_objects

In [252]: converter = lambda x: maybe_convert_objects(np.asarray(x, dtype='O'), convert_datetime=True, convert_timedelta=True)

In [253]: converter([1,2,3])
Out[253]: array([1, 2, 3], dtype=int64)

In [254]: converter([1,2,3])
Out[254]: array([1, 2, 3], dtype=int64)

In [255]: converter([1,2,'3'])
Out[255]: array([1, 2, '3'], dtype=object)

In [256]: converter([datetime.datetime(2015, 1, 1), datetime.datetime(2015, 1, 2)])
Out[256]: array(['2015-01-01T00:00:00.000000000', '2015-01-02T00:00:00.000000000'], dtype='datetime64[ns]')

In [257]: converter([datetime.datetime(2015, 1, 1), 'a'])
Out[257]: array([datetime.datetime(2015, 1, 1, 0, 0), 'a'], dtype=object)

In [258]: converter([datetime.datetime(2015, 1, 1), 1])
Out[258]: array([datetime.datetime(2015, 1, 1, 0, 0), 1], dtype=object)

In [259]: converter([datetime.timedelta(seconds=1), datetime.timedelta(seconds=1)])
Out[259]: array([1000000000, 1000000000], dtype='timedelta64[ns]')

In [260]: converter([datetime.timedelta(seconds=1), 1])
Out[260]: array([datetime.timedelta(0, 1), 1], dtype=object)

ya mungkin_convert_objects adalah konversi lunak
itu hanya akan mengonversi jika semua ini benar-benar dapat dikonversi

Saya bisa bergabung dengan .infer_objects() yang sangat sederhana dalam kasus itu. Saya pikir itu tidak akan menerima argumen apa pun?

dapat menambahkan fungsi baru dan mengubah pesan pada penghentian convert_objects untuk menunjuk ke .infer_objects() dan .to_* untuk 0,21, lalu hapus di 1.0

@jreback : Dilihat dari percakapan ini, tampaknya penghapusan convert_objects tidak akan terjadi di 0.21. Apakah lebih baik untuk menutup #15757 dan membiarkan PR baru menggantikan implementasi infer_objects (yang BTW, sepertinya ide yang bagus)?

IIUC, sejauh mana infer_objects hanya port convert_objects untuk menjadi metode DataFrame (atau hanya NDFrame secara umum)?

convert_objects memiliki logikanya sendiri dan memiliki opsi. infer_objects harus menggunakan inferensi default seolah-olah pada DataFrame (tetapi hanya kolom objek).

Ah benar, jadi maksud Anda infer_objects adalah convert_objects dengan default yang diteruskan (kurang lebih, mungkin beberapa tweak khusus untuk DataFrame )?

infer_objects seharusnya tidak memiliki opsi, cukup lakukan konversi lunak (pada dasarnya hanya memanggil maybe_convert_objects dengan opsi default

Ah, oke, itu masuk akal. Saya hanya mencoba untuk memahami dan menyusun komentar yang dibuat dalam diskusi ini dalam pikiran saya.

fyi, dibuka #16915 untuk infer_objects jika ada yang tertarik - khususnya jika Anda memiliki kasus uji tepi dalam pikiran