DEV Community: Reem Hamraz

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. 🤞