REGR: fix regression in scalar setitem with setting a length-1 array-like
State: closed

- [x] closes #46268
- [x] [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).
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

While testing the various related cases, I noticed that we don't have very consistent behaviour always, see the TODO notes in the tests. 
In pandas 1.3, we always unpacked an array-like when setting, also for object dtype. This means that for object dtype, it unpacked it for len-1, and raised an error for longer arrays:

```
In [31]: df = pd.DataFrame({"A": [1, 2, 3], "B": np.array([1, 'a', 'b'], dtype=object)})

In [32]: df.loc[0, "B"] = np.array([0])

In [33]: df
Out[33]: 
   A  B
0  1  0
1  2  a
2  3  b

In [34]: df.loc[0, "B"] = np.array([0, 1])
...
ValueError: Must have equal len keys and value when setting with an iterable
```

With the change in https://github.com/pandas-dev/pandas/pull/42780, in pandas 1.4 we started to preserve the nested object in case of len-1, but still raising for longer arrays (with object dtype column):

```
In [24]: df = pd.DataFrame({"A": [1, 2, 3], "B": np.array([1, 'a', 'b'], dtype=object)})

In [25]: df.loc[0, "B"] = np.array([0])

In [26]: df
Out[26]: 
   A    B
0  1  [0]   # <-----
1  2    a
2  3    b

In [27]: df.loc[1, "B"] = np.array([0, 1])
...
ValueError: Must have equal len keys and value when setting with an iterable
```

This is a bit inconsistent I would say, and I think we should probably long term allow setting nested data of any length _in case of object dtype column_ (the first TODO note).

Because of the above change (no longer unpacking for len-1 array), this started to error for _numeric_ columns (i.e. the actual regression reported in #46268). 

What I did in this PR is limiting the change of https://github.com/pandas-dev/pandas/pull/42780 to only object dtype, so we keep the new behaviour of preserving the nested object when setting in case object dtype, while fixing the regression for numeric data. 
(strictly speaking, we could also say that it is a regression for the object dtype case, but there I think it was actually an improvement in behaviour, and since this was already changed in 1.3.5, and nobody reported it, it seems better to keep that now)

In addition, while testing the same for Series, I noticed that for Series setitem, we only do this unpacking of len-1 array-like values for actual numpy arrays, and not for setting array-likes in general (the second TODO note).

TODO: open new issues to keep track of those TODOs and update those comments

Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Regression
description: Functionality that used to work in a prior pandas version
name: Nested Data
description: Data where the values are collections (lists, sets, dicts, objects, etc.).

Comments:
@phofl just to be clear: those TODO comments I added are interesting points (and I should open new issues for those), but fixing those are out of scope of this focused regression fix for 1.4.4 (your feedback on those questions was very welcome! just to set expectations that I don't plan to "fix" those todos here ;)). See also the longer explanation in the top post.
Yep understood this, no worries. Just wanted to coment in code to avoid misunderstandings with the references
Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

```
git checkout 1.4.x
git pull
```

2. Cherry pick the first parent branch of the this PR on top of the older branch:
```
git cherry-pick -x -m1 73e0b5eaea5b7471ee7762f7e218baba05624012
```

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

```
git commit -am 'Backport PR #48057: REGR: fix regression in scalar setitem with setting a length-1 array-like'
```

4. Push to a named branch:

```
git push YOURFORK 1.4.x:auto-backport-of-pr-48057-on-1.4.x
```

5. Create a PR against branch 1.4.x, I would have named this PR:

> "Backport PR #48057 on branch 1.4.x (REGR: fix regression in scalar setitem with setting a length-1 array-like)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the `Still Needs Manual Backport` label once the PR gets merged.

If these instructions are inaccurate, feel free to [suggest an improvement](https://github.com/MeeseeksBox/MeeseeksDev).
                
Thanks @jorisvandenbossche (failures unrelated)