A fitted statsmodels model holds more than the array of numbers most code pulls from it. The point forecast is only the smallest task that model can perform, and three built-in methods can turn the same result into a richer forecasting workflow.
Using one monthly series and one fitted model, the methods change while the underlying data and model stay the same. All three methods were checked against statsmodels 0.15.0, creating a focused path from basic forecasts to uncertainty, updated data, and seasonal forecasting.
Start With the Results Your Model Already Computed
The first trick is simple: choose the result object that matches what you need instead of taking only a list of forecast values. As Matthew Mayo puts it, “A fitted statsmodels model computes a more than just the array of numbers most code pulls out of it.” The model has already produced information that can help explain the forecast.
res.forecast(12) gives twelve numbers. That may be enough when the only requirement is a point forecast for the next twelve periods, but it leaves out the uncertainty that accompanies those estimates.
res.get_forecast(12) returns a PredictionResults object instead. That object carries the estimated uncertainty, and summary_frame() provides both predicted means and confidence intervals. The intervals do not require a separate forecasting process; they come from the same computation that produced the point forecast.
That changes the meaning of publishing a forecast without its interval. It is not just a formatting decision. It is a choice to leave out information the fitted model has already estimated.
“The intervals aren’t even extra work; they are a result of the same computation, and the shorter method simply throws them away,” Mayo writes. Reading the result object preserves that information instead of forcing the code to rebuild it.
The same idea applies to history. get_prediction can obtain fitted values over a range that includes in-sample periods, not only future observations. Mayo describes it this way: “get_prediction is this same idea applied to a range that can include in-sample periods.”
Update a Fitted Model Without Starting Over
Forecasting does not end when twelve new months arrive. The next trick uses append to add those twelve months of observations to existing data, with refit=False to avoid re-estimating parameters from scratch.
The default for append is refit=False, which reuses the estimates already available. As Mayo explains, “The default is refit=False , which reuses the estimates you already have.” This gives the model new observations without immediately computing a new set of parameters.
When enough new data has accumulated, pass refit=True to re-estimate the parameters. The choice depends on whether the new observations should only extend the current filtering process or justify computing the estimates again.
There is an important detail behind append: it re-runs the filter over the original data and the new data. When the history is long, filtering only the new observations is faster. That is where apply fits, but it serves a different purpose.
- append handles a continuation of the current data and re-runs the filter over the original and new observations.
- apply is for a different dataset rather than a continuation of the current one.
- refit=False keeps the existing estimates by default.
- refit=True re-estimates parameters when enough new data has accumulated.
This distinction keeps the update method aligned with the data being processed. A continuation calls for append, while a different dataset calls for apply.
Let STLForecast Handle Seasonal Structure
The third trick targets a series with seasonal behavior. STLForecast is an object that automates the process of decomposing a series, forecasting the seasonally adjusted part, and adding the seasonal component back.
The documentation describes STLForecast as forecasting “by first subtracting the seasonality estimated using STL, then forecasting the deseasonalized data using a time-series model, for example, ARIMA.” That sequence turns several steps into one built-in forecasting object.
There is one API detail that can cause trouble: pass the ARIMA class itself to STLForecast through model_kwargs. Do not pass ARIMA(…) instead. Mayo calls this “the first mistake most people make with it,” because STLForecast expects the class rather than a fitted instance.
That detail matters because the built-in object owns the workflow. It decomposes the series, forecasts the deseasonalized data, and returns the seasonal component to the forecast instead of requiring those steps to be rewritten separately.
Every trick here is a method that already exists on an object that has already been built. Deviating from the built-ins is not worth it in this case because the replacement code is usually longer, slower, and more error-prone.
The central lesson is direct: read the results object, use the method designed for the next task, and stop rewriting work the model has already completed. With statsmodels 0.15.0, that means preserving intervals, updating observations with the right method, and letting STLForecast manage seasonal decomposition as the workflow moves forward.
