DEPR: making copies when indexing along columns
- [x] closes #33780
- [ ] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

xref #33597 for what this might look like once the deprecation is enforced (nice perf bump)

cc @jorisvandenbossche my understanding is that we will need this deprecation for the all-1D world too.  Is that correct?  Any thoughts on nice ways to test this and avoid putting tm.assert_produces_warning in a zillion places across the code?

> my understanding is that we will need this deprecation for the all-1D world too. Is that correct?

We don't *have* to (I mean it's not tied to being 1D), but yes, I suppose we will want that to return views in the long term (although there wasn't much discussion around it in the issue). 

> Any thoughts on nice ways to test this and avoid putting tm.assert_produces_warning in a zillion places across the code?

This also indicates that users will see a zillion of such warnings .. Also, what is the way for users to silence the warning? 
So therefore, I am not really sure we should already start doing that now. Certainly because in many cases it won't actually matter for their code. The other option is to "simply" make a breaking change for pandas 2.0. > The other option is to "simply" make a breaking change for pandas 2.0

Is there precedent for this?  Per #33597, I'm OK with just making the switch immediately.

> This also indicates that users will see a zillion of such warnings .. Also, what is the way for users to silence the warning?

Good question.  I guess we'd have to give a way to opt in to the always-view behavior, or maybe a global flag to silence the warning.  Neither is particularly pretty. What do you mean with precedent? (what kind of precedent are you looking for in this case?) > What do you mean with precedent? (what kind of precedent are you looking for in this case?)

Changes that _would_ require a deprecation cycle being made without one Ah, we certainly have that ;) Check the sections "Backwards incompatible API changes" in all previous releases?   makes sense, thanks