@damonge, moving _nonlimberFKEM into nonlimber._nonlimberFKEM is technically breaking the API. However, this module seems to be private. Opinion?

Pull Request Test Coverage Report for Build 22635547529

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 158 of 165 (95.76%) changed or added relevant lines in 5 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.02%) to 97.446%

Totals
Change from base Build 21003793779:	-0.02%
Covered Lines:	6601
Relevant Lines:	6774

💛 - Coveralls

@carlosggarcia I wouldn't worry about that kind of API breakage, to be honest. Not worth wasting time on that. Is the idea that we will want to implement other non-Limber methods?

Ok. So let's merge it.

Yes, the idea behind this change of structure is to leave room for new non-limber methods. @nikosarcevic and @paulrogozenski can say more.

For the record. I forgot to mark it as approved it but I approved it.

Also, the errors were due to being too slow to push to coveralls, which had already sent a report back for those jobs that had already finished. And the lower coverage I believe it was due to a misestimation due to merging main, instead of rebasing.