GSoC Week 1 & 2: Kickoff and Refactoring build_posterior method

Hi everyone! I’m thrilled to share my journey so far in Google Summer of Code (GSoC) 2025, where I’m contributing to the sbi project. Over the first two weeks, I focused on a major refactor of the build_posterior method. An essential part of the library that is used to create a posterior distribution.

Getting Started

My project kicked off with a focus on design discussions, understanding the existing implementation, and setting up a collaborative workflow with mentors and the community. These first two weeks have been both challenging and insightful, filled with thoughtful conversations and hands-on learning.

What I Worked On

• Opened a draft pull request to begin the refactoring of the method build_posterior arguments across inference trainer classes to adopt strongly typed code.
• Wrote a design document outlining the motivation and plan for the refactor and presented different approaches to the sbi admin members.
• Read through the Optimagic enhancement proposal, focusing on sections related to algorithm selection and configuration design to bring similar approaches to the refactoring.
• Explored different methods for defining dataclasses and reduce code duplication where I came across Python’s make_dataclass as a cleaner way to manage configuration objects, but didn’t go forward with it as it doesn’t provide code completion to developers.
• Resolved merge conflicts in an existing pull request where I had previously introduced a protocol to better structure the behavior of NRE (Neural Ratio Estimator) classes.
• Continued implementation of the build_posterior refactor based on feedback from mentors.
• Studied Python best practices related to mutable default arguments, where I found a bug on an existing implementation and opened a Pull Request to fix the bug and improve code safety.

Challenges & Lessons Learned

One key challenge was thinking of different ways to refactor the build_posterior method in a way that’s modular, extensible, and backward-compatible. Communicating and validating design ideas with maintainers helped solidify the plan.

Another important lesson was understanding the pitfalls of using mutable default arguments in Python function definitions. These can cause unintended side effects when objects are shared across function calls. A safer pattern is to use None and assign defaults inside the function.

Thanks for following along! I’m grateful for the support from my mentors and the sbi community so far!