BUG: Losing information when handling of NoneTypes in pd.json_normalize

[a-theron]

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

def flatten_json(data: dict):
    sr = pd.Series(data)
    df = pd.DataFrame()
    df["jsonData"] = sr
    flat = pd.json_normalize(df['jsonData'])
    return df.join(flat)

expectedData = {
    0: {'Field1': 'SomeValue'},
    1: {'Field1': None},
    2: {},
}
expectedDf = flatten_json(expectedData)
display(expectedDf)

buggedData = {
    0: {},
    1: {'Field1': None},
    2: {},
}
buggedDf = flatten_json(buggedData)
display(buggedDf)

Issue Description

When using pd.json_normalize I expected to keep the distinction between None and NaN cells (or at the very least for the behaviour to be the same regardless of the input.

There are 2 scenarios in the example I gave:
Scenario 1 - At least one value for a specific key (resultant column in the df) in the json is not None or NaN.
In this case the cells containing None are preserved in the final df

Scenario 2 - All the values for a key (resultant column in the df) in the json payload are None or NaN.
In this case the cells containing None are not preserved in the final df, rather None is converted to NaN

The handling of None should at the very least be consistent in both scenarios. In my opinion it should retain as much information as possible, so the output of scenario 1 makes the most sense to me.

Expected Behavior

I expect to still see a NoneType value even when all the cells are either None or NaN

Installed Versions

INSTALLED VERSIONS

commit : d9cdd2e
python : 3.11.9.final.0
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.22631
machine : AMD64
processor : Intel64 Family 6 Model 140 Stepping 1, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_Australia.1252

pandas : 2.2.2
numpy : 1.26.4
pytz : 2024.1
dateutil : 2.9.0
setuptools : 68.2.2
pip : 23.3.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 8.22.2
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2024.1
qtpy : None
pyqt5 : None

[nguyen-tien-tung]

take

[a-theron]

After reviewing the documentation, I think this might not be a bug.
I think it is a result of how Pandas handles none types.
In Panda's none type documentation it states

pandas uses different sentinel values to represent a missing (also referred to as NA) depending on the data type.

Which means that the different none types (None, NaN, NaT) are used depending on the dtype of the column.
So when a column only has missing values (as shown in the "bug"), Pandas has no reference dtypes so all missing values are represented by the default (NaN) none type.

So correct me if I am wrong, but I believe this might actually part of the Panda's feature set, rather than a bug.