BUG: compatibility between pd.Timestamp() and datetime.date()

[frlm]

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

import pandas as pd
import datetime

# Returns True (correct)
datetime.datetime(2023,9,26).date() == pd.Timestamp("2023-09-26").date()

# Returns True (correct)
datetime.datetime(2023,9,26) == pd.Timestamp("2023-09-26")

# Return False (Isn't better raise an error? If programmer doesn't know it or doesn't check, he gets an unexpected behavior)
datetime.date(2023,9,26) == pd.Timestamp("2023-09-26")
datetime.datetime(2023,9,26) == pd.Timestamp("2023-09-26").date()

Issue Description

Pandas Version: 2.1.1

I am opening this issue to inform the community about the behaviour described in the reproducible example. In particular, I am observing that the comparison between the objects datetime.date() and pd.Timestamp() always returns False.
This could generate unexpected behaviour in the code if the programmer is not careful. Could a raise be added to inform the user that this equality check cannot be performed?

Expected Behavior

Raising an Error or correctly checking

Installed Versions

INSTALLED VERSIONS

commit : e86ed37
python : 3.10.12.final.0
python-bits : 64
OS : Linux
OS-release : 5.10.102.1-microsoft-standard-WSL2
Version : #1 SMP Wed Mar 2 00:30:59 UTC 2022
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : C.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.1.1
numpy : 1.25.2
pytz : 2023.3.post1
dateutil : 2.8.2
setuptools : 65.5.1
pip : 23.0.1
Cython : 3.0.2
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : 2.9.7
jinja2 : 3.1.2
IPython : 8.15.0
pandas_datareader : None
bs4 : 4.12.2
bottleneck : None
dataframe-api-compat: None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : 3.8.0
numba : 0.58.0
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : 1.11.2
sqlalchemy : 2.0.21
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[mroeschke]

Thanks for the report. Since Timestamp aims to model the standard library datetime.datetime object (since it's a subclass), comparing with datetime.date also returns False so this is the intended behavior. Closing as intentional but if the stdlib begins to raise then we can raise here too #36131