Add from_string classmethod constructor for CmdStanModel

[vankesteren]

Submission Checklist

• Run unit tests
• Declare copyright holder and open-source license: see below

Summary

This implements a basic version of instantiating a CmdStanModel from a code string. For discussion, see #757; this implements option 3 from that discussion. I've implemented the classmethod itself as well as a (basic) unit test. I've ensured code passes both flake8 and pylint.

This is a first draft, feel free to reject this pull request, to request changes, or to completely ignore 👍 I don't want to overload you as maintainers!

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Erik-Jan van Kesteren

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

• Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)

[mitzimorris]

I really don't want to see this added to the code base, given that we now have the most excellent stanplayground which does this in a browser, which seems to me, where you want to be doing quick experimentation.
https://github.com/flatironinstitute/stan-playground

[bob-carpenter]

@mitzimorris: I think the motivation is that people like to construct Stan programs programmatically out of pieces and it's a pain to have to find a location on disk that's stable to read and write from.

Personally, I don't like when people encode their models as a string in Python. It causes at least three problems. First, if you use ', you can't use vector or matrix transposition without escaping the ' and if you use ", you can't use print() with strings. The second problem is that line numbers in error messages no longer make sense. Third, you don't get syntax highlighting (unless you have a fancier editor than I have!). Having said that, lots of people seem to just write their Stan code into the Python file so there aren't multiple files to manage.

Stan Playground has its own problems with being a web app that's not under a user's control, so there's no expectation of privacy, no service level agreement for response time or uptime, etc. Of course, you could always serve it up locally, but that seems painful and doesn't interface with the rest of Python tools without saving output and importing.

[mitzimorris]

I think the motivation is that people like to construct Stan programs programmatically out of pieces and it's a pain to have to find a location on disk that's stable to read and write from.

@bob-carpenter - I was responding to this comment on the referenced issue:

But having this as a feature would be really nice nonetheless for quick experimentation. I miss it when I want to explain or try out some small model. For new users, the barrier will be lowered if you allow stan code to be passed.

but the use case Bob mentions is valid - I defer to the active cmdstanpy devs on this one.

[amas0]

I think the all the criticisms/concerns raised about encoding a Stan program as a string are valid; however, I do think there is a user experience challenge that people run into when using cmdstanpy.

Jupyter notebooks are ubiquitous in the Python data ecosystem. The notebook interface encourages not have separation between the different components of your work, whether that's code, narrative, visualizations, etc. Requiring users to separate out their Stan code to a different file breaks that paradigm. It's just ends up being awkward for users.

Of course, this paradigm isn't always good, but that doesn't mean it's not useful in some instances. I would always encourage people use better development practices, but I think compromising to meet users where they are at is also important.