GSoC 2022 Interfaces for Consistent API Design: Library-wide Discussion

[tdhoffman]

For GSoC 2022, I'm working on designing more consistent interfaces to PySAL's exploratory and inferential statistics classes. The end goal is to design a sleek new API for PySAL's statistical classes that is highly self-consistent.

To couple with related issues in spreg, mgwr, esda, spopt, and spglm, I'm creating an issue here for discussion on library-wide concerns related to this project. From discussion in the other issues, it seems like a PySAL-specific set of base classes would be most preferable to developers. While scikit-learn and multiple dispatch might not be great fits for the library, it still needs consistent standards (whether or not they conform to external rules). Creating a PySAL-specific framework would have several key advantages, like in-house maintainability and customizability.

Importantly, I'm starting this API redesign in the modeling classes (spreg first, then likely moving to mgwr, spint, and beyond). Developing common constructs for these packages is a good subproblem before moving out of the model module. To this end, I'm interested in getting your feedback on the following questions:

• What design elements would you like to see implemented in a new interface for PySAL's modeling classes?
• What design elements does PySAL's current design get right, and what design elements could be deprecated?
• Are there library/package/code structures elsewhere that might be beneficial to use or mimic in PySAL? What benefits would PySAL gain from drawing on these structures?

My drafts for this redesign can be found in pysal-base and in my copy of spreg. These are quite rough at present as development is ongoing. Descriptions of my development can be found on my blog.

Excited to hear your input!