PyFixest Integration (& more)

[s3alfisc]

Hi @jordandeklerk,

I accidentally stumbled over this package yesterday and it looks phenomenal! Writing a "common API" DiD package has actually long been on my backlog but I never got around to it.

In PyFixest, we support a range of DiD models that are not yet implemented for moderndid - the local projections, did2s, and Sun-Abraham approaches (everything is licensed under MIT). Would you be interesting in us opening PRs to your package?

We also have some other DiD tooling that might be a better fit for your package than PyFixest. You can find a quick overview of everything that we have in this vignette: https://py-econometrics.github.io/pyfixest/difference-in-differences.html the code lives in the did module in PyFixest.

Additionally, we have just spun out the regression tabling functionality out of PyFixest. The package is called maketables and has a very easy way to support additional models via a plug in approach. Let me know if you'd be interested and I'll open a PR =) (see here for details: https://py-econometrics.github.io/maketables/docs/SupportedModelClasses.html)

Last, @jsr-p has an implementation of the imputation estimator that looks great and I wanted to point you to this initiative Jonas =)

All the best, Alex

[jordandeklerk]

Hey @s3alfisc, thanks for reaching out! I’m glad you stumbled across moderndid, and I really appreciate the kind words. I’m a big fan of PyFixest.

I think the DiD coverage you mentioned would be a strong addition here, and I’d absolutely be open to PRs. This package started as a side project earlier this year, but my time has shifted quite a bit since joining the ArviZ team, so development has been slower as a solo maintainer. Contributions would make a huge difference!

I’ll make sure to take a look at the other DiD tooling you pointed to in the PyFixest did module and the maketables plugin approach. The tabling piece may be a nice fit here as the model surface area grows.

And +1 on @jsr-p’s imputation estimator implementation. Thanks for flagging that, and I’m happy to coordinate on how it could slot in cleanly.

Really appreciate the outreach, and yes, PRs are very welcome!

[s3alfisc]

Contributions would make a huge difference!

Awesome, then I will start with PRs for did2s, Sun-Abraham, Local Projections, and the maketables plug-in.

so development has been slower as a solo maintainer

I think there should be huge demand for a package like this - if you don't mind, I'll ask around a bit and see if I can find others who would be interesting in helping out here a bit =) But I will for sure also stop by every know and then to see how I can help (beyond opening the PRs mentioned above).

[jsr-p]

I agree with @s3alfisc; cool package!

I would be interested in massaging my implementation into a submodule in your package 😃
What is the core API that the implementation should satisfy, @jordandeklerk ?

[jordandeklerk]

Awesome, then I will start with PRs for did2s, Sun-Abraham, Local Projections, and the maketables plug-in.

Sounds great, I really appreciate it!

I think there should be huge demand for a package like this - if you don't mind, I'll ask around a bit and see if I can find others who would be interesting in helping out here a bit =) But I will for sure also stop by every know and then to see how I can help (beyond opening the PRs mentioned above).

Glad to hear this. I don't mind at all. The more help the better as far as I am concerned!

[jordandeklerk]

Hi @jsr-p, thanks for the kind words! Awesome job with your implementation of the imputation estimator. It looks really great.

Currently, any implementation of the didimpute submodule should probably try to conform to these established patterns:

All estimators currently return a NamedTuple with relevevant quantities such as point estimates, standard errors, confidence levels, bootstrap samples, etc. I think this can be pretty flexible for the specific estimator.

The function signature should probably look something like this give or take some arguments (whatever is relevant):

def did_impute(
    data: pd.DataFrame,
    yname: str,                     # Outcome variable column
    tname: str,                     # Time period column
    gname: str,                     # Group/cohort column (first treatment period)
    idname: str | None = None,      # Unit ID column (required for panel)
    xformla: str = "~1",            # Covariate formula 
    panel: bool = True,             # Panel vs repeated cross-section
    weightsname: str | None = None, # Sampling weights column
    alp: float = 0.05,              # Significance level
    bstrap: bool = False,           # Use bootstrap inference
    biters: int = 1000,             # Bootstrap iterations
    # ... estimator-specific parameters
) -> DIDImputeResult: # Named tuple container

As of right now, the only concrete API structures that are unified across estimators are the preprocessing functions and classes. So it would be ideal (though not necessary at this point) for any implementation to probably integrate with the preprocessing core logic. This would probably require adding new preprocessing logic for the specific estimator.

I think we could modify/add new functions eventaully for new estimators though. So I wouldn't say this is something that absolutely has to be shipped with version 1 of a new estimator.

---

Btw @s3alfisc and @jsr-p, I'm very open to feedback on the API design if you see opportunities to improve it based on any new estimators. The main goal is consistency with the rest of the package where it makes sense, but we can adapt as needed. This also goes for any documentation as well. There's quite a laundry list of things I'd like to get to for this package so any advice or guidance is always appreciated!

Looking forward to the PRs!

[jordandeklerk]

Hi @s3alfisc and @jsr-p,

FYI I've been updating documentation lately. Wanted to point you to https://moderndid.readthedocs.io/en/latest/dev/architecture.html that may help with any API design questions you may have.

Documentation is always evolving of course, but I think this gives a good starting point for any future PRs. This is certainly not a strict rubric either! I think there's plenty of room for flexibility depending on the nature of new estimators.

[s3alfisc]

This looks excellent! Really makes me want to contribute =) Will try to draft something for one of the models in pyfixest in the next week.

The section on pandas to polars conversion section made me think - are you aware of narwhals? narwhals provides you with data frame agnosticism - users can come with what they want, and narwhals handles all the underlying complexity for you.

cc @MarcoGorelli fyi =)

[jordandeklerk]

This looks excellent! Really makes me want to contribute =) Will try to draft something for one of the models in pyfixest in the next week.

The section on pandas to polars conversion section made me think - are you aware of narwhals? narwhals provides you with data frame agnosticism - users can come with what they want, and narwhals handles all the underlying complexity for you.

cc @MarcoGorelli fyi =)

Thank you! No rush at all, appreciate the kind words.

I am aware of narwhals, (@MarcoGorelli amazing project!) and tbh I'm not sure why it didn't occur to me to use this when refactoring data wrangling here. I will make this a priority though because this would be great to allow users to provide any dataframe they want. Thanks for the suggestion!

[jordandeklerk]

@s3alfisc I took a shot at implementing the plug-in approach for maketables functionality. I have some docs about it here. See this as one example of how I'm doing this. Things seem to be working pretty well so far and I've been able to make some pretty awesome tables!

Whenever you have some time, would love any feedback you have. The quality of life improvement that maketables brings is really great. Fantastic work on the package!

[s3alfisc]

This is super cool, I am very happy that it's working well for you! cc @dsliwka @felixschmitz who might also be happy about this feedback =) (btw, I am sorry for the delayed response - I was super busy developing pyfixest in the last evenings :smiling )

[dsliwka]

@s3alfisc I took a shot at implementing the plug-in approach for maketables functionality. I have some docs about it here. See this as one example of how I'm doing this. Things seem to be working pretty well so far and I've been able to make some pretty awesome tables!

Whenever you have some time, would love any feedback you have. The quality of life improvement that maketables brings is really great. Fantastic work on the package!

@jordandeklerk: Looks amazing & thanks for the kind feedback! Great to see the plugin-interface in productive use. Please let us know if you see issues in maketables that should be tackled.

[jordandeklerk]

This is super cool, I am very happy that it's working well for you! cc @dsliwka @felixschmitz who might also be happy about this feedback =) (btw, I am sorry for the delayed response - I was super busy developing pyfixest in the last evenings :smiling )

No need to apologize! Appreciate the visibility and feedback!

[jordandeklerk]

@jordandeklerk: Looks amazing & thanks for the kind feedback! Great to see the plugin-interface in productive use. Please let us know if you see issues in maketables that should be tackled.

@dsliwka Likewise, appreciate the kind feedback! Of course, I will continue to build out more functionality for different estimators and keep in mind any issues. None so far though. Love the project!