DEV Community: Satwik Sai Prakash Sahoo

Merging My First PR for GSoC!

Satwik Sai Prakash Sahoo — Mon, 15 Jun 2026 13:12:48 +0000

Hey everyone! The official coding period for Google Summer of Code (GSoC) has begun, and I am thrilled to share that my very first Pull Request (PR) for the sbi (Simulation-Based Inference) repository has been officially merged!

These first two weeks have been packed with writing code, writing tests, and most importantly, going through an incredibly insightful code review process with my mentors.

Here is a breakdown of what I worked on, the technical challenges I faced, and the best practices I learned along the way.

Laying the Foundation (PR #1872)

My GSoC project is focused on refactoring the Neural Network (NN) Builder API. Before we can build the new, shiny network builders, we need a solid foundation. This first PR was all about setting up the necessary data structures and renaming existing protocols to make room for the new architecture.

1. The New `build_context.py`

I created a new file to house the core pieces needed to set up a neural network. This centralizes how the data is prepared before it hits the network:

ZScoreConfig: Tracks how the user wants to preprocess data.
ZScoreStats: Holds the calculated mean and standard deviation for the data.
BuildContext: Bundles everything required to build a network (shapes, device, dtype, and z-score stats) into a single, clean dataclass.
compute_z_score_stats(): A helper function to calculate these statistics directly from the training tensors.

2. Clearing the Naming Space

To make the codebase more intuitive, I had to rename a few core components across 16 different trainer files:

Changed ConditionalEstimatorBuilder to ConditionalEstimatorBuildFn. This clarifies that the protocol is actually a function, not an object, and frees up the "Builder" name for upcoming classes.
Changed _EstimatorConfigBase to _EstimatorBuilderBase, giving it an empty build() method to prepare for the next phase.

Big Takeaways from Code Review

Getting the code working was only half the battle. The review process with my mentor, taught me several advanced Python and PyTorch practices.

Managing Tensor Devices

When creating the BuildContext, the data (x and theta) are passed in as PyTorch tensors. My mentor pointed out that if x and theta accidentally end up on different devices (e.g., one on CPU, one on GPU), it will cause runtime failures. I updated the code to explicitly check that both tensors share the same device and added GPU-specific pytest runs to ensure everything handles device placement gracefully.

Dataclasses and Tensor Equality

I originally set up my statistics classes as @dataclass(frozen=True). However, because they hold PyTorch tensors, this creates a subtle bug. PyTorch's implementation of equality (==) for tensors returns a boolean tensor, not a single boolean value, which breaks the dataclass equality checks.

The fix was simple but crucial:

@dataclass(frozen=True, eq=False)
class ZScoreStats:
    theta_mean: Optional[Tensor] = None
    theta_std: Optional[Tensor] = None
    x_mean: Optional[Tensor] = None
    x_std: Optional[Tensor] = None

By adding eq=False, equality becomes identity-based, completely bypassing the PyTorch tensor comparison crash.

Graceful Deprecation with PEP 562

Since ConditionalEstimatorBuilder was used by the community, we couldn't just delete the name and break everyone's code. Instead of leaving a dummy class, I learned how to use module-level __getattr__ to intercept the import and throw a FutureWarning.

def __getattr__(name: str):
    if name == "ConditionalEstimatorBuilder":
        import warnings
        warnings.warn(
            "`ConditionalEstimatorBuilder` has been renamed to "
            "`ConditionalEstimatorBuildFn`. The old name still works but will be "
            "removed in a future release. Update your import to: "
            "`from sbi.neural_nets.estimators.base import ConditionalEstimatorBuildFn`.",
            FutureWarning,
            stacklevel=2,
        )
        return ConditionalEstimatorBuildFn
    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

Refactoring Tests

I used Claude Opus to help generate initial test coverage for the new context types. It gave me class-based tests. However, the sbi standard relies heavily on function-based tests and pytest fixtures. I completely refactored the test suite to use @pytest.mark.parametrize to test valid combinations of inputs, ensuring maximum coverage with minimal, highly readable code.

What's Next?

With the foundation types successfully merged into the gsoc-2026 branch, the groundwork is officially laid out! Up next is PR #1877, where I will be adding the actual DensityEstimatorBuilder with dynamic build() dispatching.

Stay tuned for week 3 and 4 updates!

GSoC Community Bonding Period: Getting Ready to Code

Satwik Sai Prakash Sahoo — Thu, 04 Jun 2026 06:51:17 +0000

Hey everyone! Welcome back to my Google Summer of Code (GSoC) journey.

In my last post, I shared the story of how I got into open source and was selected for GSoC with NumFOCUS to work on the Neural Network Builder API Refactor project for sbi (Simulation-Based Inference).

Since the official announcement, the past three weeks have been dedicated to the Community Bonding Period. It is designed to help contributors get to know their mentors, understand the community culture, and familiarize themselves with the codebase and tools.

Here is exactly what I did during these past three weeks to get ready for the main coding phase!

The Kickoff Meeting

We started the bonding period with a great kickoff call on Google Meet. It was a joint meeting that included the mentors for both of the selected sbi projects, the selected GSoC candidates. We were also joined by the mentee who successfully completed the GSoC project for sbi last year!

Everyone introduced themselves, and it was incredibly inspiring to meet the team face-to-face (virtually!) and hear about everyone's backgrounds. Having a former GSoC student there was a huge bonus, as they shared some great insights into what to expect in the coming months.

Setting Up the Machine

A big part of getting started is making sure the development environment is properly configured. During our meetings, we discussed the machine setup in detail to ensure both candidates had everything required to run and test the sbi codebase locally without any hiccups.

Embracing AI Coding Assistants

One of the most interesting discussions we had was about using AI coding assistants. In the modern development world, tools like these are becoming standard, and our mentors actually encouraged us to use them!

However, they emphasized using them carefully and strictly following project guidelines. To help us get the most out of these tools without compromising code quality, the mentors shared some excellent Claude code tutorials and provided us with resources to level up our AI coding skills. It is all about using AI to augment our capabilities, not to blindly write code for us.

Diving into the Codebase and Planning

With the setup out of the way, the rest of the three weeks was all about reading. I spent a lot of time diving deep into the sbi codebase and reading through the documentation properly.

Understanding the architecture is critical for my API refactor project. To keep everything organized and on track, we were provided with a plan.md file. This document serves as our roadmap, outlining exactly what needs to be tackled, the skills required, and the milestones we need to hit.

What's Next?

The community bonding period was incredibly helpful. It gave me the time to get comfortable with the team, set up my workflow, and build a solid foundation before the heavy lifting begins.

Now, the official coding phase is here! I am beyond excited to start pushing commits and working on the Neural Network Builder API Refactor.

Thanks for reading, and stay tuned. I will be sharing more technical updates and lessons learned as I start writing code for GSoC!

How I Got Selected for GSoC: My Journey with sbi

Satwik Sai Prakash Sahoo — Sun, 31 May 2026 19:55:27 +0000

Hey everyone! I am super excited to share that I have been selected for Google Summer of Code (GSoC) with NumFOCUS. I will be working on the Neural Network Builder API Refactor project for the organization sbi (Simulation-Based Inference).

If you are wondering how to get started with open source or what the GSoC process is really like, here is the story of how I got here. Stay tuned, because I will keep updating you on my GSoC journey and sharing my experiences as I get deeper into the project!

Why I Started Open Source

Being a fan of Linus Torvalds, I was always fascinated by open source. Also, I wanted to test my coding skills. I wanted to know: Is my code actually good enough for the real world? In my first year of college, I spent a lot of time doing competitive programming. At the same time, I was teaching myself machine learning and mathematics, working mostly with Python and PyTorch.

Finding the Right Project

When I decided to try open source, I wanted to find an organization that actually matched what I was learning. Because I was already into machine learning and PyTorch, I went looking for something in that space.

That is how I found sbi.

Making my first Pull Request (PR) was a little scary, but the maintainers at sbi were incredibly welcoming. They patiently guided me through my early, beginner-level PRs. Thanks to their feedback, I learned so much about how to write clean, high-quality code.

The GSoC Surprise

After a few months of fixing bugs and contributing, I found out from the maintainers that sbi would be participating in GSoC this year. They encouraged me and appreciated the work I had done over the past few months, for which I will be forever grateful.

But there was one problem: I hadn't researched GSoC at all. I had no idea what the requirements were or how to write a project proposal.

Getting Help with the Proposal

Writing the proposal was tough since it was my first time. Luckily, I didn't have to do it alone.

The maintainers also stepped up to mentor me. They reviewed my proposal drafts, gave me detailed feedback, and helped me improve it step by step until it was ready.

What's Next?

All that hard work and community support paid off, and I got accepted!

The GSoC community bonding period just finished up. In my next blog post, I will share exactly what I did during this bonding period to get ready for the main coding phase.

Thanks for reading, and stay tuned!

DEV Community: Satwik Sai Prakash Sahoo

Merging My First PR for GSoC!

Laying the Foundation (PR #1872)

1. The New build_context.py

2. Clearing the Naming Space

Big Takeaways from Code Review

Managing Tensor Devices

Dataclasses and Tensor Equality

Graceful Deprecation with PEP 562

Refactoring Tests

What's Next?

GSoC Community Bonding Period: Getting Ready to Code

The Kickoff Meeting

Setting Up the Machine

Embracing AI Coding Assistants

Diving into the Codebase and Planning

What's Next?

How I Got Selected for GSoC: My Journey with sbi

Why I Started Open Source

Finding the Right Project

The GSoC Surprise

Getting Help with the Proposal

What's Next?

1. The New `build_context.py`