-
Notifications
You must be signed in to change notification settings - Fork 82
BREAKING CHANGE: cleanup entities #1286
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
base: master
Are you sure you want to change the base?
Conversation
The method in itself had no relation to `entities` (it was a static method, so no depending neither on an entity class nor an instance). It could have been kept as a `populations` helper, where it was exclusively used. Nonetheless, `check_role_validity` had the peculiar behaviour of not failing but when the value of `role` is not `None`, that granted it in my opinion the right to be removed so as to avoid confusion.
…ity` That argument actually did nothing, and linters have been complaining about this argument for almost 10 years now. It is only being marked as a breaking change for respect to the semantic versioning protocol.
The feature is now provided by simple variable assignment: ```python entity.tax_benefit_system = tax_benefit_system ``` Likewise, `entity.tax_benefit_system` becomes part of the public API (which implicitly it was as the private marker was being violated).
The feature is still provided by `CoreEntity.get_variable` when passed the optional positional or keyword argument `check_existence`. In fact, the removed method was duplicating and already existing behaviour.
1011e8b to
1459e31
Compare
|
@bonjourmauko : please take a look at |
|
We can temporise this one, it is not urgent (it is purely deprecations, so it is expected that it wreaks havoc down the line; yet all deprecations are duplicates with corresponding features). |
Depends on #1285
New features
CoreEntity.variablesDeprecations
CoreEntity.check_role_validityentities(it was a staticmethod, so no depending neither on an entity class nor an instance). It
could have been kept as a
populationshelper, where it was exclusivelyused. Nonetheless,
check_role_validityhad the peculiar behaviour ofnot failing but when the value of
roleis notNone, that granted itin the author's opinion the right to be removed so as to avoid confusion.
class_overridearg fromentities.build_entityabout this argument for almost 10 years now. It is only being marked as
a breaking change for respect to the semantic versioning protocol.
CoreEntity.check_variable_defined_for_entityCoreEntity.get_variablewhen passedthe optional positional or keyword argument
check_existence. In fact,the removed method was duplicating and already existing behaviour.
CoreEntity.set_tax_benefit_systementity.tax_benefit_systembecomes part of the public API(which implicitly it was as the private marker was being violated).
Technical changes
openfisca-extension-templatetests