-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process / return a new typed Lang class in i18n methods #183
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #183 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 33 33
Lines 1603 1640 +37
Branches 291 306 +15
=========================================
+ Hits 1603 1640 +37 ☔ View full report in Codecov by Sentry. |
085dcbb
to
6e700d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcomed change!
I see a missed opportunity for a proper type here that's not a wrapper around some dict.
If you're attached to that dict-ness, then subclass dict instead ; that'd be cleaner.
The dict-ness is just the least effort path. Code is regularly updating / merging multiple properties at once, and it is a mess / very verbose to re-implement without the dict facilities (see e.g. That being that, I would also prefer to use a proper type if this does not makes the code too verbose. Shall we use pydantic BaseModel as base class? It would be a new dependency, it would help a bit, even if it would probably not solve all issues |
(and using a proper type was also my initial trial, but I quickly realized it was not that convenient to write) |
Well I think you did not read my comment to the end and that none of your arguments make sense but given it was late when you replied, I think fresh eyes will have us agree that what I commited is simpler and has no downsides. Revert if that's not the case. I only tested via running the unit tests |
I did read it, just I'm not that attached to Let's go with I'll just replace |
Edit: |
Fix #151
Changes:
i18n.Lang
class to hold returned valuesi18n.get_language_details()
,i18n.get_iso_lang_data()
,i18n.find_language_names()
andi18n.update_with_macro
now process / return a new typedLang
classi18n.NotFound
toi18n.NotFoundError
from previous PR (forgot changelog + few wrong docstrings)