CoW: Ensure that iterrows does not allow mutating parent
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) 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.

cc @jorisvandenbossche 

Any idea on how to do this nicer?

Do you think we need a way to hand over a ref object when constructing a Series from an array at some point?
Yeah, if this is a pattern that will be used more, then we should add a helper for it. In general I think we should still try to avoid this kind of pandas object -> values -> pandas object with views _outside of the internals_ to avoid having to think about refs there.

Possible ideas to do this cleaner:

- Rely on indexing (`self.iloc[i]` to iterate over rows), and then refs will already be taken care of. But I suppose that will give a big overhead (because you repeat the dtype calculation for each row). And that's probably the same for `self._mgr.fast_xs(i)` which is special-case method in internals to get a row.
- Add a method to the BlockManager to have the core logic there (like a version of `fast_xs` but then not for a single row but all rows) Yep I agree with all your points and would also
Like to avoid it as much as possible, but it’s tricky here without hurting Performance I think.

I‘ll explore adding something on the manager level, that sounds like a good compromise Shall we short-term go for this "ugly" solution? (so at least to have correct behaviour) Probably a good idea, I think I can get something done before the actual 2.0 is out