DEV Community: Reem Hamraz

Learning to Speak C & Cython: My GSoC Summer with Astropy

Reem Hamraz — Sun, 16 Aug 2026 15:35:15 +0000

The summer is officially over. I am staring at a remarkably clean Git branch, my laptop didn't literally take off into orbit (though the CPU fans certainly tried a few times during local CI builds), and I somehow know what git rebase -i does without having to Google it in a cold sweat.

If you'd asked me back in May what I was going to be doing, I would have confidently told you I was going to "write tests for Astropy's C extensions." It sounded so neat. So contained. But open source doesn't really work like that. I came in thinking I was just going to write tests, and somewhere along the way, I ended up learning how the actual machinery underneath the Python abstraction works, how maintainers think about architecture, and how to safely catch C-level memory panics without taking down the entire interpreter.

So, here is the real story of what I did for the last few months, what broke, how we fixed it, and where the project stands now.

So, what was I actually supposed to do?

Astropy is a beast of a library. The Python-facing API is incredibly robust and beautifully documented. But underneath all those pretty Python classes is a complex, mixed-language architecture. The library relies heavily on compiled C, and Cython extensions to handle the performance-critical hot-paths.

The problem? That compiled layer was a massive testing blind spot. Before this summer, these performance-critical extensions were almost entirely tested indirectly, meaning they were only validated by calling the high-level Python wrappers. That is a risky abstraction. If a regression happens deep inside the C code, the Python layer sitting above it can accidentally mask it. You wouldn't know something was fundamentally broken until a downstream package started acting weird.

My project goal was to build a dedicated, de novo test suite that bypassed the public API completely and exercised each compiled extension module directly. This wasn't just for code coverage. It was an absolute prerequisite for three massive Astropy milestones:

The APE Split: Proving the extensions are stable enough to live in a completely separate package.
Meson Migration: An opportunity to try Meson out during a potential package split without bothering the many developers that are already watching the main repo.
Python 3.15 Limited API: Safely testing internal C-refactors for the upcoming free-threaded builds.

The mission was to harden Astropy's core stability. The reality was peeling away layers of Python abstractions until I was staring at raw memory buffers.

Turns out, "testing C extensions" is not quite as simple as it sounds

I started my summer in astropy/table, which my mentors flagged as a solid starting point. My first target was test_np_utils.py, writing a low-level suite for the join_inner Cython extension.

The thing is, Cython extensions don't want your high-level Table objects. They want raw data. I had to build a helper function, _make_join_inputs, which acted as a pre-processor. It took two arrays, concatenated them, sorted them with argsort(kind="stable"), and used a boolean diffs array to find the exact boundaries of unique keys. It output the exact np.intp bindings that Cython demanded.

Once I could feed the raw extension, I built strictly typed dataclasses (ArrayMaskPair and ExpectedResults) to hold the outputs without making the pytest matrices unreadable with massive tuples. I tested standard overlaps, but the real fun was the Cartesian edge cases. I threw O(N²) expansions at the extension, where duplicate keys joined with duplicate keys, just to prove the C extension could handle the explosive memory allocation without crashing. I also verified that it properly handles np.nan as a unique entity (since nan != nan in Python).

And all this stands as proof that I can actually write code that works, phew!

The C-Slots

Things got significantly more complicated when I moved to test_column_mixins.py. The objective here was to test the Cython __getitem__ routing in pure isolation.

I couldn't just pass a standard array. I had to create a "Shim Strategy" (so fancy), so I wrote MinimalColumn and MinimalMaskedColumn classes that inherited directly from the Cython mixins (_ColumnGetitemShim, _MaskedColumnGetitemShim) and mapped them directly onto raw NumPy arrays using .view() casting. By overriding the .data property to return a pure ndarray view, I stopped the Cython extension from returning raw memoryview buffers, which would have hard-crashed the tests. We were hitting the tp_as_mapping->mp_subscript C-slot directly.

But this is where I hit my first major hurdle.

While I was writing a test for structured arrays, indexing it with a single string, the structured dtype suddenly just dropped, and it returned a 1D array of the underlying field's type. I spent hours going down this rabbit hole, utterly convinced my test was wrong. Eventually, I found the machinery underneath: a literal trapdoor in base_getitem.

if dtype_kind == 'V' and isinstance(item, STRING_TYPES):
    return self.data[item]

Because it accessed the raw .data array, it inherited NumPy's default behavior and lost the structure. Rather than cementing this unintended behavior by writing a passing test for it, I dropped the test case and opened Issue #19827.

This was my first realization that tests aren't just a safety net; when written at this level, they act like a microscope.

And then things started breaking in interesting ways

Open source isn't just writing code, getting a green checkmark, and merging. The messy middle is where the actual work happens. I mean everyone knows that right? Yeah no sometimes people get a reality check; people is me, I am people.

The Masked Array isinstance Trap: I proudly swapped isinstance() checks for strict type(result) is ... assertions, which instantly caused my masked array tests to fail. It turns out standard ndarray slicing strips subclasses, but np.ma.MaskedArray.__getitem__ inherently preserves them. The C-slot was actively returning the MinimalMaskedColumn shim.
The CI Gatekeeper: While working on the mixins, I used an @override decorator. Python 3.12 CI matrices immediately failed because typing_extensions wasn't in the base test environment. Instead of bloating pyproject.toml with a new dependency just for one test file, I made the architectural choice to drop the decorator completely. CI went green.
Git History looking like a crime scene: At one point, a uv.lock file triggered a check-added-large-files pre-commit hook failure. My branch had some incredibly messy commits. So I took a couple of deep breaths, paced around, and after a midly dramatic breakdown, I ran git restore --staged, and fired up a local interactive rebase (git rebase -i HEAD~6) via Nano to squash the chaos into a single, clean production commit (see told ya it was simple :) )

Somewhere along the way, I stopped just writing tests

As the summer progressed, the project evolved. The APE split required not just test coverage, but rigorous structural boundaries. I started writing .pyi type stubs to define the Python-facing boundaries of compiled extensions so static type checkers could understand them without executing the C extension, not to forget the Proof of Concept, all in a days work (I'm lying, I almost cried trying the machete strategy).

The XML C-Extension Stubs (`iterparser_iterparser.pyi`)

When I looked at the C struct for the _iterparser extension, it looked like the parser accepted fd, buffersize, file, and buffer. But looking at the C struct is like looking at a map and realizing the map is wrong.

By analyzing the C-API execution (PyArg_ParseTupleAndKeywords), I discovered that file and buffer were strictly internal C-state variables generated after crossing the Python boundary. The Python __init__ only actually takes fd and buffersize. Because the C extension didn't natively support keyword argument routing here, I had to enforce positional-only arguments using the PEP 570 / marker in Python.

Even better, we had a friendly discussion about the fd.read callable. My mentor pointed out read(self->file, self->buffer...) in the C code. But tracing the Python C-API showed a Py_BuildValue("(n)", buffersize) call directly before PyObject_CallObject. The C extension was packing a C Py_ssize_t into a 1-element Python tuple. We proved the Python callable only ever receives one integer, finalizing the strict protocol signature as Callable[[int], bytes].

Dimensionality Locking in `_convolve`

For _convolve.pyx, we needed to ensure that arrays passed to the C extension matched perfectly before runtime. I used bounded TypeVar aliases (_D1, _D2, _D3) to enforce a strict mathematical rule at the static analysis level. The result, array_to_convolve, and kernel arrays can be 1D, 2D, or 3D, but type checkers now can statically flag improper use, mixing dimensionalities.

The `unit_list_proxy.c` Dependency Injection

This was easily one of the coolest things I worked on. astropy/wcs/src/unit_list_proxy.c had a massive circular dependency problem. It was relying on astropy.units.UnitBase via PyImport_ImportModule at runtime.

We discovered that cunit wasn't a normal attribute; it was a C-level mutable proxy array. Standard Python @property wrappers broke the memory linkage, meaning the C-array never received updates.

Following my mentor Clément's strategy, we scrapped the Python wrappers and built a Dependency Injection architecture. I implemented a _setup_unit_class(PyObject* unit_class) function, dynamically exposed to _wcs. It runs exactly once during Python initialization to cache the Unit class pointer in a static C variable, completely severing the heavy PyImport dependency. We updated the getitem C-slot to natively yield Unit objects (like CompositeUnit) back to Python, and made the setitem slot use duck-typing (parse_strict="warn") so it gracefully emits a UnitsWarning for garbage FITS strings instead of hard-crashing. I was super elated when I finally succeeded and to see the CI checks green? Goodness was that rewarding, so I treated myself to an ice-cream sundae!

Numerical sanity and the "Grid Trap"

I also wrote isolated suites for the astropy.timeseries periodogram C-extensions. Bypassing the high-level BoxLeastSquares API, I fed raw np.float64 memory buffers directly into the Cython boundary (_impl.pyx).

I built a SyntheticTransit fixture to inject a perfect transit dip into a simulated light curve to prove the C extension's best_objective algorithm peaked accurately.

But math is cruel :(

My tests were failing to recover a mathematically perfect period of 2.0. Why? Because I generated my frequency grid using np.linspace(1.5, 2.5, 100). If you do the floating-point math, the step size is ~0.0101. The number 2.0 literally did not exist in the array (the closest it got was 2.005). I was stuck fighting my own numerical grid. I changed it to 101 steps, and voila it hit the target perfectly!

We also dealt with a fascinating accuracy tradeoff. When using a coarse grid (1,000 points, oversample=10), the discrete phase-binning of the BLS algorithm caused the edges of the transit to smear, changing the recovered depth from a perfect 0.5 to 0.478. My mentor challenged the 5% tolerance. By fixing the linspace bug and adjusting the points, we tightened the mathematical accuracy to 1e-4 while balancing the matrix to keep the isolated test executing in under 300ms so we didn't anger the CI limits.

I ran into a similar trapdoor testing the Lomb-Scargle Cython implementation (cython_impl.pyx). I tried to test the Cython-level t.ndim != 1 error. But when I passed a 2D array for t and 1D arrays for y, np.broadcast_arrays panicked and raised a Python ValueError before the C extension ever saw it. The fix? I deliberately passed identical 2D arrays for all parameters so it survived the Python broadcasting check and successfully crashed directly on the C-boundary. Hurrayy!

The parts that didn't go according to plan

Of course, not everything matched the original proposal. My initial timeline had me delivering tests for astropy/erfa and astropy.coordinates towards the end of the summer (Deliverables 5 and 6).

The reality of open-source struck: astropy/erfa had already been spun out into the standalone pyerfa package, and astropy.coordinates was delegating its math to that external library. You can't write isolated C-extension tests for an architecture that doesn't live in your repository anymore.

Rather than viewing this as a failure, I contacted my mentors, pivoted, and spent that time significantly deepening the coverage and architectural stability of the .pyi stubs and the XML parsers.

So, where did we end up? (Current State)

The goal was to make the compiled layer testable, and I am leaving behind an architecture to ensure it stays that way.

Merged work & contributions

Table C-extensions: merged isolated tests for join_inner (PR #19458), documented jointype integer mappings (PR #19468), and added direct C-slot tests for _column_mixins (PR #19806).
XML iterparser: built structural 4-tuple boundary tests for the _iterparser C-extension and caught memory buffer behaviors (PR #19922).
Type stubs: defined the static type boundaries for _iterparser.pyi (PR #20006, positional-only) and _convolve (PR #20093, dimensionality locking).
Time parse extension: overhauled the _parse_times.c boundary test using strict type(parser) is np.ufunc assertions and byte arrays ("S24") (PR #19875).
Quantity unit extraction: fixed unit extraction in structured_to_unstructured for StructuredQuantity (PR #19106).
APE split expansion: contributed to the proof of concept for the APE split, expanding the implementation section in Clement's fork (PR #3) to define what the low-level tests look like.

Still open, waiting on review

WCS dependency injection: refactored unit_list_proxy.c to cache the Unit class pointer, severing the PyImport overhead (PR #20072).
Timeseries math engines: built exact synthetic recovery matrices for Box Least Squares (bls.c / _impl.pyx, PR #20151) and Lomb-Scargle (cython_impl.pyx, PR #20222).

The Developer Guide

Perhaps the most lasting piece of work I did was writing and merging testing_extensions.rst (PR #20239) into Astropy's core documentation. This document establishes the architectural standards for making low-level compiled modules testable. It outlines the rules for bypassing Python wrappers, strictly avoiding isinstance() at the compiled boundary, structural validation, safe exception handling using pytest.raises substring matching, and .pyi architecture. If anyone has any questions regarding the project I think this would serve as a good starting point (before the actual coding part of course).

What's left after I leave?

The work on astropy/erfa was pivoted to the external pyerfa repository, so testing that boundary remains a future task for whoever manages that standalone package.

Beyond that, the primary future work is maintenance. When a new Cython extension is updated or a C-boundary changes, these isolated tests will immediately flag it. The testing_extensions.rst guide exists specifically so future contributors don't have to stumble through the same trapdoors I did. Future contributors can use this suite as a blueprint to expand coverage into newer subpackages.

Sidenote: I plan on staying (long time). I'm not going to disappear just because GSoC is over but rather continue to contribute to this epic organization. I'll keep working, raising PRs, beefing with GitHub and most importantly, I'll help guide all those who stumble across Astropy just as Clément and Nathaniel were always there for me!!

What I actually took away from this

I came into GSoC thinking I was going to write tests. Somewhere along the way, I ended up learning how to actually reason about a mature codebase.

I learned that you have to read the C code before writing the Python test. I learned to question unexpected behavior rather than blindly cementing it into a test. I learned that CI is a judgmental gatekeeper, Git history tells a story, and numerical tolerances matter a whole lot more than just getting the test to pass. I learned that maybe breaking a huge problem into separate sections wasn't such a bad idea after all and it's this lesson that I'll be applying to my life as well.

Most importantly, I learned how maintainer-level review actually works. The feedback I got wasn't just "fix this bug," it was "let's structure this so it's statically typed, mathematically locked, and future-proof." And it really shaped my journey. I mean the Reem from December 2025 decided to open her very first PR and make huge changes in 4 different files, which ultimately was pretty overwhelming and she closed the PR. My point is that I have grown as a contributor and that makes me so very proud.

A HUGE thank you

All this is just because I had the BEST mentors EVER, Clément Robert (@neutrinoceros), and Nathaniel Starkman (@nstarman).

Clément, thank you for never once making me feel dumb for asking the same question twice, and for having the patience to let me actually sit with a hard bug instead of just handing me the fix. For taking time out from your busy schedule every week, just so that I could ask you all the questions I saved, and to go through my code, suggest changes and help me understand all the whys. You didn't just correct my code, you really changed how I think about coding. I came into this summer knowing how to write Python and I'm ending it knowing how to reason about the internals underneath.

Nathaniel, thank you for being just as generous with your time, and just as willing to slow down and explain something properly even when the answer must have felt obvious from where you were standing.

Having two mentors who both cared this much about getting it right, and not just getting it merged, made all the difference. And I couldn't be more grateful!

To the OpenAstronomy and Astropy community: thank you for letting me poke around the raw internals of your library.

Until next time,
Reem <3

Wiring the Abyss

Reem Hamraz — Thu, 30 Jul 2026 16:22:22 +0000

I can see the finish line. Send help, or snacks, or both.

The `unit_list_proxy.c` Exorcism

unit_list_proxy.c is in review. That circular dependency on astropy.units.UnitBase was a nightmare: it kept re-importing the entire units module at runtime just to check if something looked vaguely unit-shaped. So I ripped out PyImport_ImportModule completely and built a proper Dependency Injection bridge instead: astropy.units.Unit now gets handed straight to the C-layer during module init [no more knocking on Python's door mid-runtime, it just lives there now]. setitem uses that injected class to enforce FITS formatting, and it's smarter than a blunt gatekeeper about it. Feed it something like "bananas // sekonds" and it doesn't slam the TypeError hammer down; it shrugs, emits a UnitsWarning, and keeps the string around for backward compatibility [petty tolerance for legacy nonsense, but tolerance nonetheless]. It only throws a hard TypeError when the input is genuinely un-parseable garbage. And getitem, this is the actual win, stopped handing back plain strings altogether. It now returns real Unit objects, like CompositeUnit, straight across the C boundary, which is what fixed the sequence math bug that started this whole mess. Tests skip the astropy.wcs wrappers entirely and hit _wcs.Wcsprm's C-slots directly to prove the whole thing is airtight.

The `bls` Extension, Numerically Unbothered

Also finished the Box Least Squares (bls) extension, feeding typed np.float64 buffers straight into bls_impl/run_bls and bypassing the high-level API entirely. Built a SyntheticTransit fixture with a fake star, a fake dip, a fake planet doing exactly what it's told, and confirmed the C engine recovers period, depth, duration correctly. First pass, I hit some phase-binning drift and figured I'd just loosen rtol to 5e-2 and call it a day [the coward's tolerance]. Mentor feedback said otherwise. Cranked the fixture to 10,000 points, hunted down a sneaky np.linspace grid-spacing bug, and tightened rtol all the way to a genuinely crisp 1e-4. Turns out the drift was never the model's fault, it was mine. Also confirmed the early-exit flags (1 and 2) raise real ValueErrors instead of just disappearing without a word.

On Being a Translator at the Cython Border

This Cython boundary work is basically being a translator between two people who are both right and also both furious. C doesn't warn you before it breaks. Python will forgive almost anything. I'm just standing in the middle going "she just needs a float64, please don't segfault."

What's Left

One thing left: lombscargle. Then I'm done.

Tired. Wired. Diving back in for one more compile.

Coming up for Air

Reem Hamraz — Fri, 10 Jul 2026 14:53:14 +0000

After the absolute gauntlet of the past few weeks, this week finally offered a little bit of breathing room. I'm not going to lie, I needed it. But "lighter" in the open-source world doesn't mean stopping; it just means you finally have the time to sit back and actually think before you code.

Writing .pyi Stub Files

A good chunk of my time went into writing .pyi stub files. It sounds mundane on the surface, like just writing Python type hints, BUT it's actually this bizarre, highly precise exercise in translation. You are basically acting as a diplomat between the ruthless C-engine and Python's static type checkers. It's microscopic work. Every single argument has to align perfectly with how the C-level memory actually allocates it, otherwise the whole illusion shatters. It requires a sort of discipline.

My Main Target

But my main focus, and what I'm gearing up to dive back into, is the unit_list_proxy.c file.

There is a nasty runtime dependency lurking in there. Right now, the C-code aggressively tries to import a massive Python library the second it gets created, locking everything into this heavy, tangled cycle. For a minute, I was dreading having to do a complete, tear-it-down-to-the-studs refactor just to untangle it.

Thankfully, I pitched an alternative to my mentor, Clément, and he gave me the green light to run with it. We'll see how that goes.

The fix?

Instead of a massive rewrite, we are going to use structural sub-typing which is a more specific form of duck typing (I guess don't come at me if I'm wrong) right at the C-level. Rather than forcing the C-engine to check an object's exact, official DNA (which requires importing the whole Python library), we are just going to check its behavior. Does it have the method we need? If it walks like a duck and quacks like a duck, the C-engine will blindly trust that it's a duck and process it.

It is such an elegant workaround. It completely severs the nasty dependency chain without us having to burn the house down to fix the plumbing (I was pretty proud of actually thinking about it).

Thoughts..

It's a smarter, cleaner way forward. The C-layer is still intimidating, but for the first time in a while, I feel like I'm actually outsmarting the machine instead of just wrestling with it.

Back into the dark I go.

Comfort is a Trap

Reem Hamraz — Wed, 01 Jul 2026 22:24:13 +0000

I've realized something over these last few weeks. Comfort is a trap.

In Python, everything is comfortable. You have these beautiful, high-level wrappers that hide the ugly reality of how the machine actually works. But if I want to do work that matters—if I want to build things that last—I can't stay in the comfortable layers. I have to go down to where it's dark and unforgiving.

Lately, that means staring down the _iterparser C-extension.

The Raw Machine

I decided to completely bypass the Python safety nets. The goal was to mathematically prove that the underlying libexpat state machine could handle brutally malformed XML byte streams without breaking.

When you dig this deep, you realize the C-engine doesn't care about being polite. High-level code gives you clean outputs, but down here? Closing tags don't yield nice, empty strings. To save precious CPU cycles on memory reallocation, the engine just yields the closing flag along with whatever lingering text is still bleeding over in the shared memory buffer. It's messy. It's raw. But it is beautifully, ruthlessly efficient.

The standard for this kind of open-source architecture is completely unforgiving. You can't just casually check if data matches; I had to explicitly enforce strict=True on my iterables just to guarantee identical lengths and prevent silent failures.

It forces a kind of discipline I didn't know I had in me.

Ghosts in the Infrastructure

And then, of course, the infrastructure decides to humble you.

I spent hours losing my mind over a corrupted Windows virtual environment that was failing my GitHub Actions for no apparent reason. The fix? Literally just clearing the cache to force a fresh dependency rebuild. Add in Ruff pre-commit hooks aborting my commits to protect the working directory, and my patience was practically non-existent.

But I finally conquered the interactive rebase against upstream targets (git rebase -i upstream/main). I managed to squash my messy, chaotic review iterations into a single, clean production commit. I might still despise GitHub squash and rebase, but at least now I know how to wield them.

I'd be lying if i said that it isn't tiring at times. It's exhausting. It's isolating. BUT when I force the C-engine to crash on a truncated byte stream, safely catch the error, and watch the internal 4-tuple align flawlessly across the Python-C boundary...

Yeah. That's the feeling. That's why I love this.

Biting Into It: My Astropy Summer (Weeks 1-3)

Reem Hamraz — Mon, 15 Jun 2026 09:48:44 +0000

"I really want to be something in life. I don't want to be forgotten."

It's a heavy thought for a Tuesday night, but it's been bouncing around my head a lot lately. I read this Sartre quote recently about living a "toothless life", just waiting around, reserving yourself for later, and then suddenly realizing your teeth are gone. I decided a while ago that I'm not doing that. If I'm going to leave something behind, it has to be through work that actually matters.

Right now, that work looks like deliberately bypassing high-level Python APIs to aggressively test raw, compiled C-engines for Astropy.

The Weekly Grind

Juggling CS coursework while trying to wrangle Cython for Google Summer of Code is a lot. But honestly? I've been loving every damn second of it. Reading documentation in a vacuum is one thing, actually hashing out C-level memory bindings is where the reality sets in. My mentors don't just let me write code; they force me to hold my work to strict architectural standards, which honestly gives me an immense sense of accomplishment once I clear them.

`test_np_utils.py`: First Blood

Getting this merged was my first real bite into the codebase. Instead of playing it safe with high-level Astropy Table objects, I stripped away the Python wrapper to test the raw C-engine underneath. I threw every Cartesian edge case at the join_inner function just to see if the explosive $O(N^2)$ memory allocations would break it.

They didn't.

`test_column_mixins.py`: The Beast

Absolute beast of a PR. I had to write MinimalColumn shims and cast them directly onto raw NumPy arrays just to isolate the Cython __getitem__ routing. Somewhere in there I found a legitimate C-level trapdoor — indexing a structured array with a single string was silently dropping the dtype entirely. That became Issue #19827, which I later learned was actually expected behavior, so I closed it. End of story.

But the real boss fight wasn't even the code (funny, right?!). It was Git. I ran a terrifying interactive rebase in Nano to squash six messy commits before force-pushing to my branch. Truly character-building.

If it isn't clear by now, let me spell it out:

"I absolutely despise GitHub squash and rebase. Actually, I don't think we (me and GitHub) can ever be on amicable terms."

APE Split & `_parse_times.c`: Standing on Shoulders

Lately I've been laying the tracks for the APE split, writing isolated tests for the _parse_times.c extension. This was mostly building on another contributor's accepted PR, but it was enlightening to understand how other brains work. I'll be honest, I spent a good chunk of time just deciphering the existing test cases before touching anything, making sure I didn't alter their original essence.

That's weeks 1–3, folks.

It's a blur of memory buffers, strict type checking, and fighting CI matrices. But when those green checkmarks come in, and especially when I see those purple merged PRs, I know I'm actually building something.

I'm biting into it. I'm not waiting anymore.

Beyond the Abstraction

Reem Hamraz — Sun, 31 May 2026 20:14:31 +0000

The glow of the screen hits different when you're reading an email that dictates your entire summer. Getting accepted into Google Summer of Code 2026 programme for Astropy, under the OpenAstronomy umbrella, was one of those really defining moments; all I could do was stare at the screen in disbelief (I'd done it). Then, the abstraction fades away, and suddenly, you need to get down to the real work.

This post, is the first of many. I plan to keep these updates transparent and real—documenting, so it's really not just going to be about the code that ships, but rather the (not-so)basic commands I need to google, or the dumb mistakes, or the long hours spent scouring the internet for things that developers ought to know (but I don't), and the brutal reality of open-source development or at least the reality from the perspective of a first-timer (that would be me needing to google how to squash and rebase, haha fun times:| or not)

Let's break down my project

This summer, my life will revolve around Astropy's low-level test suite, or more formally speaking:

"Hardening Astropy's Core Stability"

I am skipping the wrappers and going straight for the raw C-extensions. Which, when you think about it, there is a kind of profound honesty in testing the core engine. It forces transparency. It demands technical accountability (excuse my philosophical analysis). What I meant to say is that no one can fake it you know? By the end of the day you really gotta understand what you're doing because otherwise you'll be lost as hell. So yeah, this is what I plan to do all summer and I can't wait for it! So totafreakingly excited!!

Speaking of being lost

My greatest advice to anyone starting would be to find your mentors, and I will swear upon this, that you really need to find your perfect organization and your perfect mentors! I wouldn't have even started down this path if it weren't for @neutrinoceros. It was a fateful email, and one that led to many many more and here I am. So, I'd really like to give a huge shoutout to my mentors for this project, @nstarman and @neutrinoceros. Open-source can be so intimidating, but having mentors who are just straight up transparent and value direct communication makes it all so much more manageable, and I'm pretty grateful that I have that experience.

And moreover, I am not starting from absolute zero either. We actually got some real momentum going recently. I finally got PR #19458 merged! The one adding direct tests for join_inner in table/_np_utils Cython extension. IT GOT MERGED. Though, ideally this would've been my first PR right after the community bonding period, I tackled it before-hand and well it paid off (proof that I can actually write code that works, phew).

A lil side note: I'm writing this post after the community bonding period but I'm starting from the very start so bear with me please. The next post will deep dive into my the coding details of my first and second set of test cases, mentor meetings, Astropy's dev telecon and all the wonderful stuff.

The next 2 weeks

Now that the official coding phase is here, my life for the next fortnight is basically going to be staring at architecture maps. I need get going with the test coverage for these Cython extensions. Plus, I really have to optimize my local setup so my laptop doesn't literally take off into orbit while running these low-level builds. Although @neutrinoceros did have a meeting with me, to help set me with the local setup, GitHub CLI and UV tools, plus a bunch of cool commands that have literally helped me a tonne.

I know, that it is going to be a grind, but like, a really good grind. I'll be back here in, whenever I feel like it, (though most probably within the next 2 weeks) to let you all in on more cool things I learnt over the course of these weeks. Check back then for more raw updates and probably more stories of me overcomplicating basic git commands.

Toodles!

Applying to GSoC 2026 with Astropy

Reem Hamraz — Thu, 19 Mar 2026 08:26:02 +0000

I'm working on submitting my Google Summer of Code 2026 proposal to OpenAstronomy this week, and I wanted to write a quick post about it.

The project is called Hardening Astropy's Core Stability. The short version: Astropy has C and Cython extensions powering its most performance-critical code, and none of them have direct tests. They're only tested indirectly through the public Python API, which means a bug deep in the compiled layer can sit undetected for a long time. My project is to build a test suite that targets that layer directly.

It's also groundwork for something bigger — there's a proposal in the Astropy community to eventually split the compiled extensions into a separate package. That can't happen safely without standalone tests first.

I've been contributing to Astropy since December 2025 — trying to fix the core and complex issues. That work gave me enough codebase context to write a proposal grounded in real problems I already ran into, not just ideas on paper.

If it goes well, I'll be spending the summer reading C source code, mapping calling conventions, and making a part of Astropy that almost nobody sees a lot more reliable. That sounds exactly like the kind of work I want to be doing.

Fingers crossed. 🤞