ENH: Add lazy copy for swapaxes no op

[phofl]

• xref ENH / CoW: Use the "lazy copy" (with Copy-on-Write) optimization in more methods where appropriate #49473 (Replace xxxx with the GitHub issue number)
• 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.

[phofl]

Not totally sure what to do in the other copy case. This can return views in some cases, but copy is performed on the underlying array

[jorisvandenbossche]

Suggested change

	if not copy and copy is not None and not _using_copy_on_write():
	if copy is False and not _using_copy_on_write():

[jorisvandenbossche]

Not totally sure what to do in the other copy case. This can return views in some cases, but copy is performed on the underlying array

What I think we ideally should do is in case that self.values is a view on the underlying data (i.e. only if we have a single block I assume) and so the swapped values is also a view of the original data, in that case we should construct a new BlockManager with a ref to the original manager's block.

This can be done here using some internal APIs, but to do this properly, it might be easier to have this as a method on the Manager.

[phofl]

I've used ndarray_to_mgr for now, that's basically what we need here.

[jorisvandenbossche]

I still think it's a bit cleaner to move this logic into the internals (we will need to same logic in DataFrame.transpose() as well), but fine for me to keep it like this for now.

[jorisvandenbossche]

since this is in the if check above, not needed to repeat here?

[phofl]

Thought so as well, but mypy disagrees

[jorisvandenbossche]

Ah .. When do we use a cast and when an assert to deal with such issues?

[phofl]

I prefer the assert here, but not sure if there is a general rule

Edit: I prefer assert not cast, stupid mistake in the initial post

[jorisvandenbossche]

we will need to same logic in DataFrame.transpose() as well

Another thought here: now that we are limited to max 2 dimensions in NDFrame, isn't swapaxes just the same as transpose? (for the case i and j are not the same) We could then maybe also consolidate those implementations (eg swapaxes calling transpose when appropriate)

[phofl]

Another thought here: now that we are limited to max 2 dimensions in NDFrame, isn't swapaxes just the same as transpose? (for the case i and j are not the same) We could then maybe also consolidate those implementations (eg swapaxes calling transpose when appropriate)

Sounds good! But would take a look as follow up, the implementations are quite different and want to understand how this would impact stuff. I think transpose is better, as it keeps dtypes more often if possible

[phofl]

Merging for now, happy to address comments in a follow up if there are any