You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pandas.
I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
data= {
"A": [5, 8, 11, 14],
"B": [6, 9, 12, 15],
"C": [7, 10, 13, 16],
"D": [8, 11, 14, 17],
}
# Create DataFramedf=pd.DataFrame(data)
dfABCD056781891011211121314314151617# Using loc set to assign scalar to non-existent row and columnsdf.loc["w", ["V", "T"]] =91# Resultant df (incorrect behavior)# A B C D V T# 0 5.0 6.0 7.0 8.0 b'' b''# 1 8.0 9.0 10.0 11.0 b'' b''# 2 11.0 12.0 13.0 14.0 b'' b''# 3 14.0 15.0 16.0 17.0 b'' b''# w NaN NaN NaN NaN 91 91
Issue Description
This is an issue that is present in pandas versions 2.2.0+: performing loc set to assign a scalar to non-existent rows and columns results in the "new" column values being empty byte values b'' instead of NaN values (based on previous pandas behavior).
# Prior to version 2.2.0 (basically 2.1 and before), the expected behavior was this:""" A B C D V Ta 5.0 6.0 7.0 8.0 NaN NaNb 8.0 9.0 10.0 11.0 NaN NaNc 11.0 12.0 13.0 14.0 NaN NaNd 14.0 15.0 16.0 17.0 NaN NaNw NaN NaN NaN NaN 91.0 91.0"""# Any non-existent data for rows/columns that were supposed to be assigned data were# given NaN values.# In pandas versions 2.2.0+, these NaN values are now b'', empty byte values.""" A B C D V Ta 5.0 6.0 7.0 8.0 b'' b''b 8.0 9.0 10.0 11.0 b'' b''c 11.0 12.0 13.0 14.0 b'' b''d 14.0 15.0 16.0 17.0 b'' b''w NaN NaN NaN NaN 91 91"""
Installed Versions
INSTALLED VERSIONS
commit : bdc79c1
python : 3.9.18.final.0
python-bits : 64
OS : Darwin
OS-release : 23.4.0
Version : Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8
Pandas version checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of pandas.
I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
Issue Description
This is an issue that is present in pandas versions 2.2.0+: performing loc set to assign a scalar to non-existent rows and columns results in the "new" column values being empty byte values
b''
instead of NaN values (based on previous pandas behavior).This issue does not occur if only new columns are created or if only new rows are created.
As you can see, when only new columns are added, NaN values are used in place of "unknowns"
The same is the case with only new rows being added - NaN values are used in place of "unknowns"
Expected Behavior
Installed Versions
INSTALLED VERSIONS
commit : bdc79c1
python : 3.9.18.final.0
python-bits : 64
OS : Darwin
OS-release : 23.4.0
Version : Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8
pandas : 2.2.1
numpy : 1.26.0
pytz : 2023.3.post1
dateutil : 2.8.2
setuptools : 68.0.0
pip : 23.3.1
Cython : None
pytest : 7.4.2
hypothesis : None
sphinx : 5.0.2
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.2
IPython : 8.18.1
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.12.3
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.8.4
numba : None
numexpr : 2.8.4
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 10.0.1
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.13.0
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None
The text was updated successfully, but these errors were encountered: