Finalizing the Interface Guidelines Design Doc

Note: I’m burying the lede on the off chance that announcing the beta leads to a deluge of bug reports.

PyStan 3 Beta 1 is ready. PyStan 3 offers a user interface which respects the guidelines described in the long-stewing “Interface Guidelines”.

If you have a moment, please check to see if your favorite model works with PyStan 3 in approximately the way you anticipate. There is a new API (hence version 3) so some small changes are going to be needed. There’s a draft upgrading guide which may be helpful.

I’d also welcome RStan devs’ comments on the interface. The interface follows the design document. If it deviates from the design document, that’s likely a bug. Also, if there are problems with the interface design document, now seems like the time to make changes.

More about PyStan 3

PyStan 3 is a complete rewrite. It standardizes variable and function names. It introduces automatic caching of fits and models. It uses stanc3. It’s also featherweight. It uses 40% fewer lines of code than CmdStanPy (“a lightweight interface to Stan”) and 68% fewer lines of code than Pystan 2. Despite adding features and fixing long-standing issues (e.g., CVODES support), PyStan 3 should be easier to maintain than PyStan 2. PyStan 3 requires Python 3.7 or higher and works on Linux and macOS. Windows is not supported at this time.

PyStan 3 has a more limited scope than PyStan 2. PyStan 3 provides a Python interface to a subset of the Stan C++ functions in the stan::services namespace, starting with stan::services::hmc_nuts_diag_e_adapt (the default sampler). In order to provide a stable platform for other developers to build on, to support reproducible scientific research, and to guarantee releases of PyStan within 48 hours of new releases of the Stan C++ library, PyStan 3 avoids providing functionality in excess of the functionality provided by these explicitly-supported stan::services C++ functions.

PyStan 3 will introduce a plugin interface so others can write independent packages which provide functionality which is not provided by stan::services functions (e.g., check_diagnostics, stansummary). A separate design document describing this idea is in the works.

New Goal: Timely Releases. A significant new goal for PyStan is to have timely releases. PyStan should come out within 48 hours of a new release of Stan. In order to make sure this goal is achieved, I’m proposing a moratorium on adding new supported stan::services functions, hardware architectures, operating systems, or Python distributions. Once there’s a track record of at least two on-time releases, this moratorium can be reconsidered.

At the present moment it does not seem realistic to promise Windows support and timely releases. Given the choice between the two, timely releases seems more important. Moreover, there is limited harm in setting aside, for the moment, the question of supporting Windows. CmdStanPy (which supports Windows) now exists (and didn’t previously). Moreover, the new, permissive license of PyStan 3 serves as an open invitation to the Windows community to develop a fork, if they see fit.

1 Like


What are the main blockers for windows support? I know windows can be a bit of a bother but if there are clear blockers I could try to help out

There several issues. Some are blockers. Some can be addressed with workarounds. Some simply impose additional maintenance burdens. No quick fixes here, in my opinion.

Linux testers are still welcome. Any macOS testing will need to wait. A problem with linking surfaced.

Here’s a link to the issue:

pystan beta 3 macOS wheels should work now. Sorry for the hiccup.