subplots=True automatic xlim considers nan values since 0.24

[JoElfner]

Code Sample,:

df = pd.DataFrame(np.random.rand(10, 2))
df.iloc[5:, 1] = np.nan
df.iloc[:5, 0] = np.nan

figs, axs = plt.subplots(2, 1)
df.plot.line(ax=axs, subplots=True, sharex=False)

Problem description

The code sample above produces two plots with different x-limits in pandas version 0.23.4, whereas in 0.24.0 both subplots share the same x-limits.
In my opinion the behavior of pandas version 0.23.4 should be correct, whereas the behavior of 0.24.0 resembles setting sharex=True.

Looking at the changelog, I haven't found any informationen on an intended change, thus I report it as a bug.

Is there any workaround for this which is still using automatic x-limit scaling?
Separate line plotting for example does not solve the problem:

figs, axs = plt.subplots(2, 1, sharex=False)

df.iloc[:,0].plot.line(ax=axs[0], subplots=False)
df.iloc[:,1].plot.line(ax=axs[1], subplots=False)

Expected Output

Expected output is attached as pdf.

Output of pd.show_versions() for 0.24.0

INSTALLED VERSIONS

commit: None
python: 3.7.1.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 63 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: en
LOCALE: None.None

pandas: 0.24.0
pytest: 4.0.2
pip: 18.1
setuptools: 40.6.3
Cython: 0.29.2
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.2.0
sphinx: 1.8.2
patsy: 0.5.1
dateutil: 2.7.5
pytz: 2018.7
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.8
feather: None
matplotlib: 3.0.2
openpyxl: 2.5.12
xlrd: 1.2.0
xlwt: 1.3.0
xlsxwriter: 1.1.2
lxml.etree: 4.2.5
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None
gcsfs: None

Output of ``pd.show_versions() for 0.23.4

Expected output
``

INSTALLED VERSIONS

commit: None
python: 3.7.1.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 63 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: en
LOCALE: None.None

pandas: 0.23.4
pytest: 4.0.2
pip: 18.1
setuptools: 40.6.3
Cython: 0.29.2
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.2.0
sphinx: 1.8.2
patsy: 0.5.1
dateutil: 2.7.5
pytz: 2018.7
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.8
feather: None
matplotlib: 3.0.2
openpyxl: 2.5.12
xlrd: 1.2.0
xlwt: 1.3.0
xlsxwriter: 1.1.2
lxml: 4.2.5
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

[gfyoung]

cc @TomAugspurger

Feel free to change the milestone as you see fit. That being said, this sounds like a behavior change (whether correct or intentional or not).

[JoElfner]

Imho seing this from a perspective of someone who is working with timeseries 24/7, this change of behavior should be unintentional.
Having synchronized axis is covered by sharex=True, while the behavior of the 0.23.4 "un"shared x-axis currently requires much larger effort to reproduce. Automatically sharing the x-axis of subplots (even though they are not shared in the meaning of setting new limits etc.) is imho not a desired output when working with data.
Thus I'd strongly prefer the behavior of version 0.23.4 .

[TomAugspurger]

All else equal, we probably want to match matplotlib's behavior. But we would need to understand why this changed first. It'd be helpful if someone could bisect which commit caused the change.

[TomAugspurger]

Pushing off 0.24.2.

[arvinnick]

take

[arvinnick]

take