What are the limitations from treatying formulaic as a drop-in replacement for patsy? about formulaic HOT 11 CLOSED

Thanks. statsmodels would definitely be interested in picking up formulaic. statsmodels/statsmodels#6858 We have models that have formulas in R but we can't support with patsy, which has proven hard to extend.

from formulaic.

Hi again @bashtage ,

The formula grammar should be largely identical, however there are transformations that I have not implemented. For example, I have not implemented support for arbitrary contrast matrices. Support can easily be added for these things, I just haven't needed them for my use-cases. I am not aware of any limitations from a framework perspective. If something in particular is valuable to you, I can definitely look at including it.

The API is different, obviously, so you won't be able to just import formulaic and have everything work transparently.

from formulaic.

I put some time today into documentation. It doesn't render quite as well as it will in mkdocs, but you can see a comparison of the grammars here: https://github.com/matthewwardrop/formulaic/blob/a19ebfd77c8129fd5827218588053432b489e7a9/docs/basic/formulas.md .

from formulaic.

Does formulaic avoid eval and allows pickling of formula information?

from formulaic.

@josef-pkt eval is avoided when there are no python transforms involved (e.g. https://github.com/matthewwardrop/formulaic/blob/master/formulaic/materializers/base.py#L283). As soon as there are Python transforms involved, an eval will occur. Code is compiled into an abstract syntax tree, modified slightly, and evaluated (e.g.

As for pickling... yes. Formulas and ModelSpec instances can be pickled.

from formulaic.

There was recently a stackoverflow question, that I don't find anymore, asking for a safe eval in patsy when users of their program provide the formula string.

I never really use eval, but something that restricts what can be run in formula strings would be good to have for users that get formula strings from someone else.

In general I think avoiding eval or having a safe eval would be good to have also if it doesn't allow all features.
(E,g, I think it's weird that R formulas take the data from the outer scope when users don't provide them explicitly. That's too much magic for my taste.)

from formulaic.

Aye. This "magic" is used by formulaic in its model_matrix(..) sugar method, largely for compatibility with expectations from patsy, but also because it is sometimes convenient. If you use the Formula(...).get_model_matrix(..) this magic does not occur.

I'll add an issue for later thought about adding a safe mode!

from formulaic.

@bashtage I'm hoping to wrap up a new major release shortly :). Did you find any other issues in your testing?

from formulaic.

I'm going to close this one out for now. Formulaic is heading toward stability now, and I'm hopeful a 1.0 release can be made before the end of the year (if not sooner). I'll create a separate issue to document the migration from patsy.

from formulaic.

from formulaic.

Not yet! I'll bump it up the priority list.

from formulaic.