The latest articles on DEV Community by Reem Hamraz (@reemhamraz). https://dev.to/reemhamraz https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3833351%2F77914e3e-884c-4fc1-8fd3-2c53b8e91097.jpeg https://dev.to/reemhamraz en Reem Hamraz Thu, 19 Mar 2026 08:26:02 +0000 https://dev.to/reemhamraz/applying-to-gsoc-2026-with-astropy-4389 https://dev.to/reemhamraz/applying-to-gsoc-2026-with-astropy-4389 <p>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.</p> <p>The project is called <strong>Hardening Astropy's Core Stability</strong>. 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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Fingers crossed. 🤞</p> webdev ai programming productivity