Enhancement qeq integration #11
Conversation
Walkthrough
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #11 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 6 6
Lines 156 169 +13
=========================================
+ Hits 156 169 +13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
quienesquien/person.py (4)
32-36: Add return_type to computed_field for JSON schema accuracy.Declare the output type to ensure correct schema generation and downstream tooling.
- @computed_field + @computed_field(return_type=str) def peso1(self) -> str: # peso1 is required for backward compatibility with previous version. return str(self.coincidencia)
37-47: Also add return_type for fecha_nacimiento_date.This helps expose the correct type in the model schema.
- @computed_field + @computed_field(return_type=dt.date) def fecha_nacimiento_date(self) -> dt.date | None: if not self.fecha_nacimiento: return None try: return dt.datetime.strptime( self.fecha_nacimiento, '%d/%m/%Y' ).date() - except (TypeError, ValueError): + except (ValueError): return NoneNote: TypeError is unlikely after the truthiness check and Pydantic's coercion to str; catching ValueError should suffice.
68-71: Simplify final return (Ruff SIM103).Replace the if/return/else with a direct boolean return.
- if curp and self.curp and curp != self.curp: - return True - - return False + return bool(curp and self.curp and curp != self.curp)
58-71: Optional: Normalize CURP comparison (trim and uppercase) to avoid false mismatches.Data often varies in case and surrounding whitespace. Normalizing reduces false positives without changing intended semantics.
def is_potential_false_positive( self, date_of_birth: dt.date | None = None, curp: str | None = None ) -> bool: if ( date_of_birth and self.fecha_nacimiento_date is not None and self.fecha_nacimiento_date != date_of_birth ): return True - return bool(curp and self.curp and curp != self.curp) + curp_normalized = curp.strip().upper() if curp else None + self_curp_normalized = ( + self.curp.strip().upper() if self.curp else None + ) + return bool( + curp_normalized + and self_curp_normalized + and curp_normalized != self_curp_normalized + )If you adopt this, consider adding/adjusting tests to cover case/whitespace variations for CURP.
tests/test_person.py (1)
57-93: Solid scenario matrix for is_potential_false_positive; consider adding ids for readability.Parametrized cases are comprehensive. Adding ids improves test output readability when cases fail.
@pytest.mark.parametrize( 'p_nacimiento, p_curp, input_date, input_curp, expected_result', - [ + [ # Different birth dates - should be potential false positive ('13/11/1953', None, dt.date(1953, 11, 14), None, True), # Same birth dates - should not be potential false positive ('13/11/1953', None, dt.date(1953, 11, 13), None, False), # Different CURPs - should be potential false positive (None, 'LOOA531113HDFPBR07', None, 'DIFFERENT_CURP_123', True), # Same CURPs - should not be potential false positive (None, 'LOOA531113HDFPBR07', None, 'LOOA531113HDFPBR07', False), # Both date and CURP different - should be potential false positive ( '13/11/1953', 'LOOA531113HDFPBR07', dt.date(1953, 11, 14), 'DIFFERENT_CURP_123', True, ), # Both date and CURP same - should not be potential false positive ( '13/11/1953', 'LOOA531113HDFPBR07', dt.date(1953, 11, 13), 'LOOA531113HDFPBR07', False, ), # No data to compare - should not be potential false positive (None, None, None, None, False), # Person has data but no input data - should not be false positive ('13/11/1953', None, None, None, False), (None, 'LOOA531113HDFPBR07', None, None, False), ('13/11/1953', 'LOOA531113HDFPBR07', None, None, False), # Input data but person has no data - should not be false positive (None, None, dt.date(1953, 11, 13), 'LOOA531113HDFPBR07', False), - ], + ], + ids=lambda p: f"p_dob={p[0]}_p_curp={p[1]}_in_dob={p[2]}_in_curp={p[3]}_res={p[4]}", )If you adopt CURP normalization, add one case asserting that differing case/whitespace does not trigger a false positive.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
quienesquien/person.py(3 hunks)quienesquien/version.py(1 hunks)tests/test_person.py(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
⚙️ CodeRabbit Configuration File
**/*.py: Enforce Relative Imports for Internal ModulesEnsure that any imports referencing internal modules use relative paths. However, if modules reside in the main module directories (for example /src or /library_or_app_name) —and relative imports are not feasible—absolute imports are acceptable. Additionally, if a module is located outside the main module structure (for example, in /tests or /scripts at a similar level), absolute imports are also valid.
Examples and Guidelines:
- If a module is in the same folder or a subfolder of the current file, use relative imports. For instance: from .some_module import SomeClass
- If the module is located under /src or /library_or_app_name and cannot be imported relatively, absolute imports are allowed (e.g., from library_or_app_name.utilities import helper_method).
- If a module is outside the main module directories (for example, in /tests, /scripts, or any similarly placed directory), absolute imports are valid.
- External (third-party) libraries should be imported absolutely (e.g., import requests).
**/*.py:
Rule: Enforce Snake Case in Python Backend
- New or Modified Code: Use snake_case for all variables, functions, methods, and class attributes.
- Exceptions (Pydantic models for API responses):
- Primary fields must be snake_case.
- If older clients expect camelCase, create a computed or alias field that references the snake_case field.
- Mark any camelCase fields as deprecated or transitional.
Examples
Invalid:
class CardConfiguration(BaseModel): title: str subTitle: str # ❌ Modified or new field in camelCaseValid:
class CardConfiguration(BaseModel): title: str subtitle: str # ✅ snake_case for new/modified field @computed_field def subTitle(self) -> str: # camelCase allowed only for compatibility return self.subtitleAny direct use of camelCase in new or updated code outside of these exceptions should be flagged.
`*...
Files:
quienesquien/version.pyquienesquien/person.pytests/test_person.py
🪛 Ruff (0.12.2)
quienesquien/person.py
68-71: Return the condition bool(curp and self.curp and curp != self.curp) directly
Replace with return bool(curp and self.curp and curp != self.curp)
(SIM103)
🔇 Additional comments (3)
quienesquien/version.py (1)
1-1: LGTM: Version bump aligns with newly added public API.The dev version increment is appropriate given the new computed field and method additions.
tests/test_person.py (2)
9-26: LGTM: Extra fields assertions reflect Pydantic v2 behavior.Validating lowercase keys via model_extra is correct and future-proof.
29-55: Good parameter coverage for fecha_nacimiento parsing.Covers happy path and multiple failure modes.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
quienesquien/person.py (2)
37-47: Trim whitespace before parsing date to reduce spurious parse failuresInputs with trailing/leading spaces (e.g., "01/01/2000 ") will currently raise and return
None. Stripping before parsing is safer and keeps behavior lenient without changing the API.Apply this diff:
@property def fecha_nacimiento_date(self) -> dt.date | None: - if not self.fecha_nacimiento: + raw = self.fecha_nacimiento + if not raw: return None try: - return dt.datetime.strptime( - self.fecha_nacimiento, '%d/%m/%Y' - ).date() + return dt.datetime.strptime(raw.strip(), '%d/%m/%Y').date() except (TypeError, ValueError): return None
58-71: Simplify boolean return, avoid double parsing, and address Ruff SIM103
- Return the condition directly (addresses Ruff SIM103).
- Cache
fecha_nacimiento_dateto avoid parsing twice.- Behavior remains identical.
Apply this diff:
def is_potential_false_positive( self, date_of_birth: dt.date | None = None, curp: str | None = None ) -> bool: - if ( - date_of_birth - and self.fecha_nacimiento_date is not None - and self.fecha_nacimiento_date != date_of_birth - ): - return True - - if curp and self.curp and curp != self.curp: - return True - - return False + dob = self.fecha_nacimiento_date + return bool( + (date_of_birth and dob is not None and dob != date_of_birth) + or (curp and self.curp and curp != self.curp) + )Optional (confirm intent first): If CURP can arrive with inconsistent casing/spacing or empty strings, consider normalizing to reduce false mismatches:
def is_potential_false_positive( self, date_of_birth: dt.date | None = None, curp: str | None = None ) -> bool: - dob = self.fecha_nacimiento_date - return bool( - (date_of_birth and dob is not None and dob != date_of_birth) - or (curp and self.curp and curp != self.curp) - ) + dob = self.fecha_nacimiento_date + # Normalize CURP values if provided + curp_norm = (curp or "").strip().upper() + self_curp_norm = (self.curp or "").strip().upper() + return bool( + (date_of_birth and dob is not None and dob != date_of_birth) + or (curp_norm and self_curp_norm and curp_norm != self_curp_norm) + )Please confirm:
- Do upstream sources ever send lowercase or whitespace-padded CURPs?
- Should empty strings be treated as “unknown” (current truthiness check ignores them)?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
quienesquien/person.py(3 hunks)quienesquien/version.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- quienesquien/version.py
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
⚙️ CodeRabbit Configuration File
**/*.py: Enforce Relative Imports for Internal ModulesEnsure that any imports referencing internal modules use relative paths. However, if modules reside in the main module directories (for example /src or /library_or_app_name) —and relative imports are not feasible—absolute imports are acceptable. Additionally, if a module is located outside the main module structure (for example, in /tests or /scripts at a similar level), absolute imports are also valid.
Examples and Guidelines:
- If a module is in the same folder or a subfolder of the current file, use relative imports. For instance: from .some_module import SomeClass
- If the module is located under /src or /library_or_app_name and cannot be imported relatively, absolute imports are allowed (e.g., from library_or_app_name.utilities import helper_method).
- If a module is outside the main module directories (for example, in /tests, /scripts, or any similarly placed directory), absolute imports are valid.
- External (third-party) libraries should be imported absolutely (e.g., import requests).
**/*.py:
Rule: Enforce Snake Case in Python Backend
- New or Modified Code: Use snake_case for all variables, functions, methods, and class attributes.
- Exceptions (Pydantic models for API responses):
- Primary fields must be snake_case.
- If older clients expect camelCase, create a computed or alias field that references the snake_case field.
- Mark any camelCase fields as deprecated or transitional.
Examples
Invalid:
class CardConfiguration(BaseModel): title: str subTitle: str # ❌ Modified or new field in camelCaseValid:
class CardConfiguration(BaseModel): title: str subtitle: str # ✅ snake_case for new/modified field @computed_field def subTitle(self) -> str: # camelCase allowed only for compatibility return self.subtitleAny direct use of camelCase in new or updated code outside of these exceptions should be flagged.
`*...
Files:
quienesquien/person.py
🪛 Ruff (0.12.2)
quienesquien/person.py
68-71: Return the condition bool(curp and self.curp and curp != self.curp) directly
Replace with return bool(curp and self.curp and curp != self.curp)
(SIM103)
🔇 Additional comments (2)
quienesquien/person.py (2)
1-1: LGTM: datetime import alias is appropriateUsing
import datetime as dtkeeps call sites concise and readable. No issues.
32-36: Good call removing redundant @Property for peso1Keeping only
@computed_fieldpreserves serialization while avoiding duplication. Backward compatibility is maintained via attribute access.
…nacimiento_to_date and update is_potential_false_positive to matches_data with improved logic
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
quienesquien/person.py (1)
51-56: Explicitly handle key collisions when lowercasingmodel_extraThe current comprehension
lowercase_extra = { k.lower(): v for k, v in self.model_extra.items() }will silently overwrite values if the payload contains both
"FOO"and"foo". You should make the behavior deterministic (e.g. first-wins) or fail fast to avoid hidden data loss.Locations to update:
- quienesquien/person.py: lines 51–56
Example “first-wins” patch:
- lowercase_extra = { - k.lower(): v for k, v in self.model_extra.items() - } + lowercase_extra = {} + for k, v in self.model_extra.items(): + lk = k.lower() + # keep the first occurrence; ignore any later collisions + if lk in lowercase_extra: + continue + lowercase_extra[lk] = v self.model_extra.clear() self.model_extra.update(lowercase_extra)If you’d rather raise on duplicates, let me know and I can provide a
ValueErrorvariant.
♻️ Duplicate comments (1)
quienesquien/person.py (1)
58-67: Semantics ofmatches_dataalign with prior review consensusReturns False only on mismatches when both sides are present; otherwise True. This matches the agreed behavior for partial data availability.
🧹 Nitpick comments (4)
quienesquien/person.py (2)
37-46: Consider caching and narrowing the exception scope infecha_nacimiento_to_date
- Avoid re-parsing the same string on each access by using
@cached_property(date is immutable post-init).- Since you already guard with
if not self.fecha_nacimiento, catchingValueErroris sufficient (TypeError should not occur).Apply this diff within the selected lines:
- @property + @cached_property def fecha_nacimiento_to_date(self) -> dt.date | None: @@ - except (TypeError, ValueError): + except ValueError: return NoneAnd add this import at the top of the file:
from functools import cached_property
61-66: Simplify nested conditionals and avoid recomputing the date propertyStreamlines logic per Ruff SIM102 and avoids repeating the property computation.
- if date_of_birth and self.fecha_nacimiento_to_date: - if self.fecha_nacimiento_to_date != date_of_birth: - return False - if curp and self.curp: - if curp != self.curp: - return False + dob = self.fecha_nacimiento_to_date + if date_of_birth and dob and dob != date_of_birth: + return False + if curp and self.curp and curp != self.curp: + return Falsetests/test_person.py (2)
23-26: Strengthen assertions to verify uppercase keys are removedIn addition to checking lowercase entries, assert uppercase keys aren’t present post-normalization.
assert person.model_extra['campo_extra1'] == 'valor1' assert person.model_extra['campo_extra2'] == 'valor2' + assert 'CAMPO_EXTRA1' not in person.model_extra + assert 'CAMPO_EXTRA2' not in person.model_extra
41-55: Nit: rename test to mirror property nameAlign test name with
fecha_nacimiento_to_datefor consistency and easier grep.-def test_fecha_nacimiento_date( +def test_fecha_nacimiento_to_date(
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
📒 Files selected for processing (3)
quienesquien/person.py(3 hunks)quienesquien/version.py(1 hunks)tests/test_person.py(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- quienesquien/version.py
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
⚙️ CodeRabbit Configuration File
**/*.py: Enforce Relative Imports for Internal ModulesEnsure that any imports referencing internal modules use relative paths. However, if modules reside in the main module directories (for example /src or /library_or_app_name) —and relative imports are not feasible—absolute imports are acceptable. Additionally, if a module is located outside the main module structure (for example, in /tests or /scripts at a similar level), absolute imports are also valid.
Examples and Guidelines:
- If a module is in the same folder or a subfolder of the current file, use relative imports. For instance: from .some_module import SomeClass
- If the module is located under /src or /library_or_app_name and cannot be imported relatively, absolute imports are allowed (e.g., from library_or_app_name.utilities import helper_method).
- If a module is outside the main module directories (for example, in /tests, /scripts, or any similarly placed directory), absolute imports are valid.
- External (third-party) libraries should be imported absolutely (e.g., import requests).
**/*.py:
Rule: Enforce Snake Case in Python Backend
- New or Modified Code: Use snake_case for all variables, functions, methods, and class attributes.
- Exceptions (Pydantic models for API responses):
- Primary fields must be snake_case.
- If older clients expect camelCase, create a computed or alias field that references the snake_case field.
- Mark any camelCase fields as deprecated or transitional.
Examples
Invalid:
class CardConfiguration(BaseModel): title: str subTitle: str # ❌ Modified or new field in camelCaseValid:
class CardConfiguration(BaseModel): title: str subtitle: str # ✅ snake_case for new/modified field @computed_field def subTitle(self) -> str: # camelCase allowed only for compatibility return self.subtitleAny direct use of camelCase in new or updated code outside of these exceptions should be flagged.
`*...
Files:
quienesquien/person.pytests/test_person.py
🧬 Code Graph Analysis (1)
tests/test_person.py (1)
quienesquien/person.py (3)
Person(12-67)fecha_nacimiento_to_date(38-46)matches_data(58-67)
🪛 Ruff (0.12.2)
quienesquien/person.py
61-62: Use a single if statement instead of nested if statements
(SIM102)
64-65: Use a single if statement instead of nested if statements
Combine if statements using and
(SIM102)
🔇 Additional comments (5)
quienesquien/person.py (2)
1-1: LGTM: explicit datetime import is appropriateUsing
import datetime as dtis clear and consistent with usage across the file.
32-36: LGTM:peso1as a Pydantic@computed_fieldThis keeps backward compatibility while avoiding persisting the field. The return type
strmatches the intended behavior.tests/test_person.py (3)
1-4: LGTM: test imports and typingParametrization via
pytestand explicit typing improve clarity and static checking.
9-16: LGTM: type-hinted test functionThe explicit return type and typed
dict[str, Any]support tooling (mypy/ruff).
57-132: LGTM: comprehensive coverage formatches_dataGreat matrix of cases for both DOB and CURP, including presence/absence conditions. This aligns well with the method’s intended semantics.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
quienesquien/person.py (3)
37-46: Consider trimming whitespace before parsing fecha_nacimientoReal-world feeds often include leading/trailing spaces. Trimming improves robustness without changing semantics. Also keeps None on empty strings post-trim.
Apply this diff:
@property def fecha_nacimiento_to_date(self) -> dt.date | None: - if not self.fecha_nacimiento: + if not self.fecha_nacimiento: return None try: - return dt.datetime.strptime( - self.fecha_nacimiento, '%d/%m/%Y' - ).date() + value = self.fecha_nacimiento.strip() + if not value: + return None + return dt.datetime.strptime(value, '%d/%m/%Y').date() except (TypeError, ValueError): return None
48-56: Lowercasing extra keys may cause collisions (potential data loss)If two extras differ only by case (e.g., FOO and foo), one will overwrite the other after lowercasing. If this scenario is possible, define a collision policy (keep-first, keep-last, or aggregate) and cover it with a test.
I can propose an implementation that preserves first value and records collisions under a reserved key (e.g., case_collisions). Let me know if you want that diff.
58-64: Verify business rule for “no data available” and make CURP comparison resilientCurrent logic returns False when neither side has data or when only inputs or only model have data. That matches the new tests but diverges from the earlier discussion where “no data” might still be considered a possible match. Please confirm the intended behavior.
Additionally, CURP comparison will often be case-insensitive and may include stray spaces. Normalizing both sides improves match reliability.
Apply this diff to normalize CURP (non-breaking for current tests, but more robust):
def matches_data( self, date_of_birth: dt.date | None = None, curp: str | None = None ) -> bool: dob = self.fecha_nacimiento_to_date - match_dob = bool(dob and dob == date_of_birth) - match_curp = bool(self.curp and self.curp == curp) + match_dob = bool(dob and dob == date_of_birth) + curp_val = (self.curp or "").strip().upper() + curp_in = (curp or "").strip().upper() + match_curp = bool(curp_val and curp_in and curp_val == curp_in) return match_dob or match_curpIf the intended behavior is to consider “no data available” as a possible match, we can adjust the return accordingly and update tests. I can draft that variant too.
tests/test_person.py (2)
29-55: Optionally add a whitespace case for fecha_nacimiento parsingIf you adopt trimming in fecha_nacimiento_to_date, include a case with leading/trailing spaces to lock the behavior.
Apply this diff after adopting the parsing change:
@pytest.mark.parametrize( 'fecha_nacimiento_input, expected_date', [ ('13/11/1953', dt.date(1953, 11, 13)), + (' 13/11/1953 ', dt.date(1953, 11, 13)), (None, None), ('', None), ('invalid-date', None), ('1953-11-13', None), ('13/11', None), ('13-11-1953', None), ], )
57-109: Parameterization is thorough; consider case-insensitive CURP test if you normalizeThe matrix covers key scenarios, including mismatches and missing data. If you normalize CURP to be case-insensitive, add a test with mixed case to prevent regressions.
Example to add (only if code is updated to normalize CURP):
# Same CURPs (None, 'LOOA531113HDFPBR07', None, 'LOOA531113HDFPBR07', True), + # Same CURP with different case and surrounding spaces (normalized) + (None, 'looa531113hdfpbr07', None, ' LOOA531113HDFPBR07 ', True),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
quienesquien/person.py(3 hunks)quienesquien/version.py(1 hunks)tests/test_person.py(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- quienesquien/version.py
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
⚙️ CodeRabbit Configuration File
**/*.py: Enforce Relative Imports for Internal ModulesEnsure that any imports referencing internal modules use relative paths. However, if modules reside in the main module directories (for example /src or /library_or_app_name) —and relative imports are not feasible—absolute imports are acceptable. Additionally, if a module is located outside the main module structure (for example, in /tests or /scripts at a similar level), absolute imports are also valid.
Examples and Guidelines:
- If a module is in the same folder or a subfolder of the current file, use relative imports. For instance: from .some_module import SomeClass
- If the module is located under /src or /library_or_app_name and cannot be imported relatively, absolute imports are allowed (e.g., from library_or_app_name.utilities import helper_method).
- If a module is outside the main module directories (for example, in /tests, /scripts, or any similarly placed directory), absolute imports are valid.
- External (third-party) libraries should be imported absolutely (e.g., import requests).
**/*.py:
Rule: Enforce Snake Case in Python Backend
- New or Modified Code: Use snake_case for all variables, functions, methods, and class attributes.
- Exceptions (Pydantic models for API responses):
- Primary fields must be snake_case.
- If older clients expect camelCase, create a computed or alias field that references the snake_case field.
- Mark any camelCase fields as deprecated or transitional.
Examples
Invalid:
class CardConfiguration(BaseModel): title: str subTitle: str # ❌ Modified or new field in camelCaseValid:
class CardConfiguration(BaseModel): title: str subtitle: str # ✅ snake_case for new/modified field @computed_field def subTitle(self) -> str: # camelCase allowed only for compatibility return self.subtitleAny direct use of camelCase in new or updated code outside of these exceptions should be flagged.
`*...
Files:
tests/test_person.pyquienesquien/person.py
🧬 Code Graph Analysis (1)
tests/test_person.py (1)
quienesquien/person.py (3)
Person(12-64)fecha_nacimiento_to_date(38-46)matches_data(58-64)
🔇 Additional comments (2)
quienesquien/person.py (1)
32-35: Good change: use only @computed_field for peso1Dropping the redundant @Property and keeping a computed field is the right call for Pydantic v2. The implementation is clear and type-safe.
tests/test_person.py (1)
9-27: Tests correctly reflect lowercase normalization of model_extraGood update to assert against model_extra with lowercase keys and to type the test for MyPy.
Summary by CodeRabbit
New Features
Bug Fixes / Improvements
Tests
Chores