Skip to content
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

test: encapsulate periods module #1138

Draft
wants to merge 94 commits into
base: master
Choose a base branch
from

Conversation

bonjourmauko
Copy link
Member

@bonjourmauko bonjourmauko commented Jul 28, 2022

Fixes #1269
Part of #1061
Part of #1062
Part of #1063
Supersedes #1139
Supersedes #1043
Depended upon by #1146

Breaking changes

Renames
  • Rename periods.period.get_subperiods to periods.period.subperiods.
Deprecations
  • Deprecate INSTANT_PATTERN
    • The feature is now provided by periods.isoformat.fromstr
  • Deprecate instant_date.
    • The feature is now provided by periods.instant.date.
  • Deprecate periods.{unit_weight, unit_weights, key_period_size}.
    • These features are now provided by periods.dateunit.
  • Deprecate periods.intersect.
    • The feature has no replacement.
  • Make periods.parse_period stricter.
    • For example 2022-1 now fails.
  • Refactor periods.period.contains as __contains__.
    • For example subperiod in period is now possible.
Structural changes
  • Transform Period.date from property to method.
    • Now it has to be used as period.date() (note the parenthesis).
  • Transform Instant.date from property to method.
    • Now it has to be used as instant.date() (note the parenthesis).
  • Rationalise the reference periods.
    • Before, there was a definite list of reference periods. For example,
      period.first_month or period.n_2.
    • This has been simplified to allow users to build their own:
      • period.ago(unit: DateUnit, size: int = 1) -> Period.
      • period.last(unit: DateUnit, size: int = 1) -> Period.
      • period.this(unit: DateUnit) -> Period.
  • Rationalise date units.
    • Before, usage of "month", YEAR, and so on was fairly inconsistent, and
      providing a perfect hotbed for bugs to breed.
    • This has been fixed by introducing a new dateunit module, which
      provides a single source of truth for all date units.
    • Note that if you used periods.YEAR and the like, there is nothing to
      change in your code.
    • However, strings like "year" or "ETERNITY" are no longer allowed (in
      fact, date unit are int enums an no longer strings).

Technical changes

  • Add typing to openfisca_core.periods.
  • Fix openfisca_core.periods doctests.
  • Document openfisca_core.periods.

Bug fixes

  • Fixes incoherent dates.
  • Fixes several race conditions.

@bonjourmauko bonjourmauko mentioned this pull request Jul 28, 2022
17 tasks
@bonjourmauko bonjourmauko requested review from a team July 28, 2022 19:53
@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch from 804a3cd to 24cafc0 Compare July 29, 2022 01:44
Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

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

Thank you for these contributions! I still don't understand how to validate doctests, and I suffered a lot from trying to set them straight (cf. #1134). I see here that we in the end ignore errors for the “periods” module. If that is indeed the case, then could you help me understand what is the point of “fixing” those tests? 🙂

CHANGELOG.md Outdated Show resolved Hide resolved
openfisca_core/periods/instant_.py Show resolved Hide resolved
openfisca_core/periods/period_.py Show resolved Hide resolved
setup.cfg Outdated Show resolved Hide resolved
openfisca_tasks/test_code.mk Show resolved Hide resolved
@MattiSG
Copy link
Member

MattiSG commented Jul 29, 2022

In order to ease future reviews, when you open a PR that depends on another one, could you please make it explicit in the description? 🙂 This will make it easier to review 😊

@bonjourmauko
Copy link
Member Author

Thank you for these contributions! I still don't understand how to validate doctests, and I suffered a lot from trying to set them straight (cf. #1134). I see here that we in the end ignore errors for the “periods” module. If that is indeed the case, then could you help me understand what is the point of “fixing” those tests? 🙂

Hi. Actually this PR make periods' doctest run (that's how I fixed them), so for them to be part of the test suite. What is ignored, at least for now, are tests' type checks, that's it.

Doctests are valuable in that they're the rare expression of unit tests in this library, coming from the contributors who gave birth to much the codebase.

@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch 2 times, most recently from 583cedd to 57b74ca Compare July 31, 2022 09:51
@bonjourmauko bonjourmauko requested a review from MattiSG July 31, 2022 09:53
@bonjourmauko
Copy link
Member Author

Hello @MattiSG ! I hope to have addressed all of your concerns. I have also updated the description to make it clear that this PR only addresses "tests", including those in the docstrings (doctests).

@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch from 22457c5 to 9d1c0c8 Compare July 31, 2022 13:58
@bonjourmauko bonjourmauko added the kind:refactor Refactoring and code cleanup label Jul 31, 2022
@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch 2 times, most recently from a12d131 to bc9e1aa Compare July 31, 2022 19:23
Copy link
Member

@MattiSG MattiSG left a comment

Choose a reason for hiding this comment

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

I cannot review this as it depends on #1141 that is disputed, and I don't support changing so many dependencies in an untestable way (cf. #1140 (comment)).

In order to ease reviews, could you please avoid force pushing once the PR has been opened, and rely instead on fixup commits if necessary? 🙂 Otherwise, I cannot rely on GitHub’s presentation of what has “changed since last review”, forcing me to spend time reviewing the same changeset again.

@bonjourmauko
Copy link
Member Author

I cannot review this as it depends on #1141 that is disputed, and I don't support changing so many dependencies in an untestable way (cf. #1140 (comment)).

Understood.

In order to ease reviews, could you please avoid force pushing once the PR has been opened, and rely instead on fixup commits if necessary? 🙂 Otherwise, I cannot rely on GitHub’s presentation of what has “changed since last review”, forcing me to spend time reviewing the same changeset again.

OK.

@bonjourmauko bonjourmauko requested a review from MattiSG August 1, 2022 19:02
@bonjourmauko
Copy link
Member Author

@MattiSG I've had cleanup as much as I can.

IMHO both readability and test coverage have improved, which is a triple win:

  1. We know several functions to deprecate soon.
  2. We can now more safely extend periods! :) (I've found some bugs downstream already).
  3. I forgot this one (something related to types, contracts, and maintainability).

@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch from 80c4880 to 3a36901 Compare November 21, 2022 10:59
@bonjourmauko bonjourmauko requested a review from a team November 21, 2022 11:00
@openfisca openfisca deleted a comment from coveralls Dec 1, 2022
@bonjourmauko bonjourmauko force-pushed the doctests/doctests-standalone branch from 3a36901 to 1dc83c9 Compare December 1, 2022 17:20
@MattiSG
Copy link
Member

MattiSG commented Dec 19, 2022

Would this be suitable @MattiSG for your proposal of a release candidate?

Yes, of course, this is a good case for #1159. But I want to stress once more that #1159 is not about allowing the use of release candidates, but about allowing replacing code review by extensive testing in some contexts. In the given case, I understand that @benjello says testing on France would be welcome. If you want to simplify that testing by using a release candidate (as opposed to a local clone), sure, do it! No need for #1159 for that 😉

f"{str(self.unit)}."
)

def this(self, unit: DateUnit) -> Period:
Copy link
Member Author

Choose a reason for hiding this comment

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

@benjello look from here below, what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

@bonjourmauko
Copy link
Member Author

@eraviart What do you think?

@bonjourmauko bonjourmauko marked this pull request as draft October 1, 2024 02:55
@bonjourmauko bonjourmauko changed the title [7/17] Encapsulate periods module test: encapsulate periods module Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:refactor Refactoring and code cleanup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix periods doctests
3 participants