BUG: Pandas 1.0.5 → 1.1.0 behavior change on DataFrame.apply() where func returns tuple

[dechamps]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Code Sample, a copy-pastable example

print(
  pd.DataFrame([['orig1', 'orig2']])
  .apply(func=lambda col: ('new1', 'new2')))

Output of Pandas 1.0.5

0    (new1, new2)
1    (new1, new2)
dtype: object

Output of Pandas 1.1.0

      0     1
0  new1  new1
1  new2  new2

It is not clear to me if this behaviour change is intended or not. I couldn't find anything obvious in the release notes.

Possibly related: #35517, #34909 @simonjayhawkins @jbrockmendel

This broke my code, which is actively relying on tuples being treated as scalars and stored as single objects (instead of being laid across the dataframe).

Output of pd.show_versions()

INSTALLED VERSIONS

commit : d9fff27
python : 3.6.9.final.0
python-bits : 64
OS : Linux
OS-release : 4.19.104+
Version : #1 SMP Wed Feb 19 05:26:34 PST 2020
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.1.0
numpy : 1.19.1
pytz : 2018.9
dateutil : 2.8.1
pip : 19.3.1
setuptools : 49.2.0
Cython : 0.29.21
pytest : 3.6.4
hypothesis : None
sphinx : 1.8.5
blosc : None
feather : 0.4.1
xlsxwriter : None
lxml.etree : 4.2.6
html5lib : 1.0.1
pymysql : None
psycopg2 : 2.7.6.1 (dt dec pq3 ext lo64)
jinja2 : 2.11.2
IPython : 5.5.0
pandas_datareader: None
bs4 : 4.6.3
bottleneck : 1.3.2
fsspec : 0.7.4
fastparquet : None
gcsfs : None
matplotlib : 3.2.2
numexpr : 2.7.1
odfpy : None
openpyxl : 2.5.9
pandas_gbq : 0.11.0
pyarrow : 0.14.1
pytables : None
pyxlsb : None
s3fs : 0.4.2
scipy : 1.4.1
sqlalchemy : 1.3.18
tables : 3.4.4
tabulate : 0.8.7
xarray : 0.15.1
xlrd : 1.1.0
xlwt : 1.3.0
numba : 0.48.0

[jbrockmendel]

which is actively relying on tuples being treated as scalars and stored as single objects

If you have a viable way to avoid this in your code, I'd encourage you to use it. Regardless of how this issue is addressed, tuples-as-scalars is fragile

[dechamps]

If you have a viable way to avoid this in your code, I'd encourage you to use it. Regardless of how this issue is addressed, tuples-as-scalars is fragile

Yep. Well at least this issue forced me to clean up my code :) I'm now wrapping the value inside a fully opaque container object.