ENH: also check type of right DataFrame to determine (sub)class of result DataFrame

[jorisvandenbossche]

Currently, we use the type of the left object to construct the result of pd.merge:

pandas/pandas/core/reshape/merge.py

Lines 731 to 732 in 445bb9f

	typ = self.left._constructor
	result = typ(result_data).__finalize__(self, method=self._merge_type)

For GeoPandas users, this means that the order of the arguments passed matters: pd.merge(df, gdf, ..) (or df.merge(gdf, ..)) returns a DataFrame while pd.merge(gdf, df, ...) (or gdf.merge(df, ..)) returns a GeoDataFrame. This can be surprising for users.

I think it should be rather easy / safe to also check the type of the right object and use that class (if left is a non-subclassed pandas.DataFrame, otherwise left still has "precedence")

API breaking implications

This can result in a different class type as return value. But for subclasses that are mostly compatible with pandas.DataFrame (and only add functionality), this should not have a big impact.

[erfannariman]

Just to be sure I understand you correctly, in both cases pd.merge(df, gdf) or pd.merge(gdf, df) you expect a DataFrame returned. What about gdf.merge(df)?

[jorisvandenbossche]

in both cases pd.merge(df, gdf) or pd.merge(gdf, df) you expect a DataFrame returned

Not necessarily (the goal for GeoPandas would be to have it return a GeoDataFrame in both cases), but I would like to defer that decision to the subclass' _constructor, which can decide to return a DataFrame or subclass.
Right now we always use left._constructor, and so I would like to also use right._constructor in case right is a DataFrame subclass and left not.