Skip to content

Conversation

@MiniCodeMonkey
Copy link
Member

Summary

Fixes #12 - Census field appends (like census2024) were not being included in geocoding responses even though the raw JSON from the API included them.

Problem

The _parse_fields() method was hardcoding only three census years:

  • census2010
  • census2020
  • census2023

When users requested census2024 or any other census year, the data was returned by the API but not parsed into the response object.

Solution

Implemented dynamic census field parsing:

  1. Dynamic Detection: The parser now automatically detects any field matching the pattern census + digits (e.g., census2024, census2025)

  2. Smart Filtering: Only parses census fields that are defined in the GeocodioFields model to maintain type safety

  3. Future-Proof: Adding support for new census years only requires adding a single line to the GeocodioFields dataclass - no changes to parsing logic needed

Changes

  • Modified src/geocodio/client.py: Replaced hardcoded census parsing with dynamic detection
  • Modified src/geocodio/models.py: Removed slots=True from GeocodioFields to allow dynamic field passing (backwards compatible)
  • Added comprehensive test in tests/unit/test_geocode.py to verify all census fields are parsed

Backwards Compatibility

No breaking changes

  • All existing census fields continue to work exactly as before
  • Removal of slots=True has negligible performance/memory impact (~56 bytes per instance)
  • Public API remains unchanged

Testing

  • ✅ All 54 existing unit tests pass
  • ✅ New test verifies census2010, census2020, census2023, and census2024 all parse correctly
  • ✅ Test uses real address: 1640 Main St, Sheldon, VT 05483

Example Usage

response = client.geocode(
    {"city": "Burlington", "state": "VT", "street": "149 Church St", "postal_code": "05401"},
    fields=["census2010", "census2020", "census2023", "census2024"],
)

# All census fields now properly accessible
print(response.results[0].fields.census2024.tract)  # Now works! 🎉

Add test case to verify that all census year fields (census2010,
census2020, census2023, census2024) are properly parsed and included
in the response.

This test currently demonstrates the bug where census2024 and other
years beyond 2023 are not being parsed even though the API returns
them.

Relates to #12
Replace hardcoded census year parsing (census2010, census2020, census2023)
with dynamic detection and parsing of any census field returned by the API.

Changes:
- Modified _parse_fields() to automatically detect and parse any field
  matching the pattern "census" + digits (e.g., census2024, census2025)
- Removed slots=True from GeocodioFields to allow dynamic field passing
  via **kwargs (backwards compatible, negligible performance impact)
- Only parses census fields that are defined in the GeocodioFields model

Benefits:
- Fixes issue where census2024 was not being parsed
- Future-proof: new census years only require adding a field definition
  to GeocodioFields, no changes needed to parsing logic
- Maintains backwards compatibility with all existing census fields

Fixes #12
Copy link
Contributor

@funkatron funkatron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much better!

@MiniCodeMonkey MiniCodeMonkey merged commit 8b74f92 into main Oct 24, 2025
1 check passed
@mjwhansen
Copy link

@MiniCodeMonkey do we know how many users were impacted by this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fields not returning any additional data

3 participants