🧹 Refactor read_parquet to improve code health - #23
Conversation
This commit addresses a code health issue where the `read_parquet` function in `pysus/api/client.py` was overly long and complex. It extracts the query construction and schema mode resolution into a new `_build_read_parquet_query` helper, and the validation digit (DV) application logic into an `_apply_dv_to_query` helper. The original method now simply orchestrates these two parts.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
1 participant
🎯 What: The
read_parquetmethod inpysus/api/client.pywas overly long (116 lines). It handles schema matching, query execution, and an optional digit validation logic. This PR splits it into three logical functions.💡 Why: Refactoring large functions improves readability and maintainability. It's now much easier to digest how schema resolution works vs how the validation digit is applied.
✅ Verification: I ran
poetry run pytest pysus/tests/and all 1535 tests passed.✨ Result: The code is cleaner, modular, and does not alter any existing behaviors.
PR created automatically by Jules for task 10963870623612946449 started by @devdudumuniz