DEV Community: Reem Hamraz

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