Pandas version checks
-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pandas.
-
[x] I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
import yfinance as yf
import pandas as pd
# Step 1: Getting the data
ticker = "AAPL"
data = yf.download(ticker, start="2020-01-01", end="2025-07-13", auto_adjust=True, progress=False)
# Step 3: Reduce to "Close" and copy
data = data[["Close"]].copy() # Note the use of .copy()
# Step 3: Calculate rolling averages
shortWindow = 20
# NOTE: Re-running the following line (in e.g. a Jupyter notebook cell) results in a column full of NaNs.
data[f"SMA{shortWindow}"] = data["Close"].rolling(window=shortWindow).mean()
Issue Description
When running a simple rolling mean assignment on a copied DataFrame, the operation works as expected on first execution, but subsequent executions result in columns full of NaNs, even though .copy() was used explicitly to break view ties.
This behavior suggests that .rolling() or the assignment mechanism is not fully stateless or clean between executions, which violates expectations around .copy() providing safe memory isolation.
Expected Behavior
After using .copy() on the sliced DataFrame—data = data[['Close']].copy()—I expect the object to be fully decoupled from its original state, and for repeated assignments to data['SMA20'] = data['Close'].rolling(20).mean() to behave identically and reliably, regardless of how many times the line is executed.
Instead, the observed behaviour is as follows:
- On the first execution,
.rolling().mean()works correctly. - On any subsequent execution, the assigned columns become full of NaNs.
- This occurs even though
.copy()was used on the entire DataFrame.
Confirmed Environment Behavior
This issue was tested in:
- ✅ Pandas 1.5.3 — No issue: repeated
.rolling().mean()assignments behave as expected. - ❌ Pandas 2.3.1 (Replit script & JupyterLab) — Repeated assignment results in columns filled with NaNs.
This confirms the issue is a regression introduced in Pandas 2.x. The behavior is reproducible across multiple environments and interfaces.
🔄 Update: Bug Persists Even with .copy() on the Input Series
I believe I have further confirmed that the issue is not due to view/copy ambiguity of the input data.
I tested the following pattern, using .copy() explicitly on the input Series before applying .rolling(), as shown below:
# Create a clean copy of the 'Close' column
closeData = data["Close"].copy()
# Assign rolling mean result to new column
data[f"SMA{shortWindow}"] = closeData.rolling(window=shortWindow).mean()
However, re-running this assignment line a second time still results in the SMA20 column being filled with NaNs. This happens even though closeData is a deep copy, isolated from any previous DataFrame state.
This suggests that:
- The issue is not caused by shared views or copy/reference issues in the input.
- The bug may instead be related to reassigning the same target column (
SMA20) multiple times with a rolling result — possibly due to internal caching, memory reuse, or stale index alignment in Pandas’ internalBlockManager.
The bug continues to occur in both:
- ✅ Replit script execution (not as a notebook)
- ✅ JupyterLab environment
This further supports the conclusion that the bug is environment-independent, and likely a regression in core Pandas 2.x logic for repeated rolling assignments.