REGR: ensure DataFrame.select_dtypes() returns a copy

[jorisvandenbossche]

• closes BUG: DataFrame.select_dtypes returns reference to original DataFrame #48090
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

This was caused by the performance improvement in #42611, because _mgr._get_data_subset doesn't return a copy in contrast to indexing columns with iloc. This just adds a copy option to _get_data_subset, to keep all other improvements from #42611 (the performance obviously decreases again because of the additional copy, but it's still faster than before #42611)

[villebro]

LGTM, thanks for the fix @jorisvandenbossche !

[jreback]

the original patch was for performance

this preserves?

[jorisvandenbossche]

@jreback see the explanation in the top post

This preserves part of the performance improvement. But the improvement of #42611 "too big" since it also removed a copy of the data that it shouldn't have.

[jreback]

can u show the asv results

[jorisvandenbossche]

Using the same code snippet as in #42611, I got:

In [2]: %timeit self.time_select_dtype_string_exclude(dtype)
1.64 ms ± 158 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)  <-- previous code before perf improvement
38.5 µs ± 279 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)  <-- main
740 µs ± 17.9 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)  <-- this PR

The slowdown compared to main is fully due to the copy. All the other improvements from #42611 still give a 2x improvement compared to before.

[jreback]

great ty

this actually somewhat answers the question of how CoW would impact (asked in another issue)

[jbrockmendel]

if we do end up adding copy=True keywords where relevant, could do the same here eventually

[jbrockmendel]

instead of adding a keyword in the Manager method could we just do a .copy after _get_data_subset?

[jorisvandenbossche]

Yes, good point. I was originally thinking to add it here to ensure that the manager can be smarter to know what needs to be copied and what not. But since the predicate is based on the block dtype, this can never split any blocks, so I suppose there will never be such a case where the subset might already be a copy. So yes, doing a .copy() here is indeed much simpler.

There is one difference though: combine (used by _get_data_subset) doesn't do consolidation, while copy() does. So if your original dataframe is not fully consolidated, the current PR keeps more of the performance improvement of #42611. Of course, at the cost of an unconsolidated return value and a potential later consolidation.

Either way is fine for me. Doing a simpler copy() will also keep it closer to the previous behaviour since iloc also consolidates I think.

[jbrockmendel]

let's do the copy outside of internals

[simonjayhawkins]

all green, I think all comments addressed. will merge later today if no objections.

[simonjayhawkins]

will merge later today

b4 1.5.0rc0