Add optional raw spec parameter for x13_arima_analysis()

[ropeladder]

• tests added / passed.
• code/documentation is well formatted.
• properly formatted commit message.

This commit adds an option to pass in a raw .spec file to the x13_arima_analysis() function, either as a path or as a string.

We needed a way to use more advanced configuration options for x13, but adding all the specifications to the statsmodels function itself seemed like an exercise in futility. (the manual for x13 is nearly 300 pages) The string substitution is hopefully not too brittle.

[bashtage]

It happens below, but if the user passes a raw spec you should trap that error seperatrly and let them know there is a problem with their spec.

[ropeladder]

I'm not clear what you mean here. Are you saying it should parse or otherwise validate the raw spec file before sending it to x13? Or that there should be a separate path for spec file errors?

[bashtage]

Lower in the file there is an exception handelign block that raises if somethign bad happens. You shoudl seperate the cases where statsmodels wrote the spec file from where the user directly passed the spec, so that you can tell the user that something is wrong with their spec.

[ropeladder]

Thanks for clarifying. Rather than adding separate handling logic, I added in an extra warning when the x13 error occurs with a user-provided spec file. The error returned by the existing _check_errors() function does a good job of showing where the errors are line-by-line already, so it didn't seem worth it to add a separate error check.

[bashtage]

Looking at this, why not allow the user to pass additional options beyone what is known. It looks like this can be of type dict[str, Union[dict[str, ??], str]]. This would just add these to the statsmodels generated spec.

[ropeladder]

That could definitely be useful for adding miscellaneous parameters. Since rawspec expects something that will essentially replace the spec file it might make more sense to add a second parameter called "addspec" or something, to make it clearer that it's not replacing the spec file outright.

[ChadFulton]

Looks pretty good to me, thanks @ropeladder! I have a few questions / comments.

[ChadFulton]

I think the intention here is to raise an error if any of those arguments are set, but doesn't this just test if the value True is in that list?

[ropeladder]

Oops! Should work now.

[ChadFulton]

Technically it might be more idiomatic here to do a try/except block like:

try:
    with open(rawspec) as f:
        rawspec_text = f.read()
except FileNotFoundError:
    if "{" in rawspec:
         rawspec_text = rawspec
    else:
         raise ValueError("rawspec argument provided but not valid path"
                                      " or spec string")

[ropeladder]

open() doesn't like super long filenames, so I used except (OSError, FileNotFoundError):.

[ChadFulton]

What happens in the case that the user doesn't have any outputs already defined?

[ropeladder]

I added more splicing to deal with other scenarios.

[ChadFulton]

I think this probably needs a little more explanation for how the user is expected to set up their spec file. e.g.:

• You must have a series{} block that does not contain data or file arguments.
• You must have a save{} block.

[ropeladder]

Added some details.

[ChadFulton]

LGTM. Do you have anything else planned, or are you happy with it now? @bashtage is there anything else you'd like to see here before it is merged?

Thanks again, great addition!

[ropeladder]

LGTM. Do you have anything else planned, or are you happy with it now? @bashtage is there anything else you'd like to see here before it is merged?

Thanks again, great addition!

That should be it, thanks!

[ChadFulton]

Thanks @ropeladder!