Preserve circular Fourier subclasses in conversion factories

[FlorianPfaff]

Summary

Fix CircularFourierDistribution conversion factories so the target-centric convert_distribution(source, TargetSubclass, ...) API returns the requested circular Fourier subclass instead of silently falling back to the base CircularFourierDistribution.

Bug

convert_distribution dispatches to TargetSubclass.from_distribution(...). CircularFourierDistribution.from_distribution and from_function_values were staticmethods and hard-coded CircularFourierDistribution when constructing results.

As a result, a caller requesting a subclass through the public conversion gateway received a base CircularFourierDistribution. The same subtype loss occurred when calling an inherited from_function_values factory directly.

Both paths inside from_distribution were affected:

• the exact circular-Dirac Fourier coefficient path;
• the sampled-density path, which delegated to the base class's from_function_values.

Fix

• make from_distribution a classmethod;
• construct the Dirac conversion result through cls(...);
• delegate sampled-density conversion through cls.from_function_values(...);
• make from_function_values a classmethod and construct through cls(...).

No Fourier mathematics, coefficient scaling, transformations, or existing base-class behavior is changed.

Regression coverage

Added focused tests for:

1. VonMisesDistribution -> CircularFourierSubclass through convert_distribution;
2. CircularDiracDistribution -> CircularFourierSubclass through convert_distribution;
3. direct inherited CircularFourierSubclass.from_function_values(...).

All three assert that the requested concrete subclass is preserved.

Scope / validation

• based directly on current main at baac3b1736bb8e81eafc1e3f69e10104636103b9;
• 2 commits ahead, 0 behind at PR creation;
• production diff is 12 lines (7 additions, 5 deletions) in one factory file;
• one 59-line regression test file added;
• full local pytest execution was not available in this connector-only environment; GitHub Actions is the repository-wide validation path.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Max errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no		no	6.76s
✅ JSON	prettier	7	0	0		0	0.6s
✅ JSON	v8r	7		0		0	5.05s
✅ MARKDOWN	markdownlint	68	0	0		0	2.16s
✅ MARKDOWN	markdown-table-formatter	68	0	0		0	0.55s
✅ PYTHON	black	1989	15	0		0	68.78s
✅ PYTHON	isort	1989	27	0		0	3.02s
✅ REPOSITORY	betterleaks	yes		no		no	1.21s
✅ REPOSITORY	checkov	yes		no		no	37.09s
✅ REPOSITORY	git_diff	yes		no		no	0.21s
✅ REPOSITORY	secretlint	yes		no		no	111.55s
✅ REPOSITORY	syft	yes		no		no	2.62s
✅ REPOSITORY	trivy-sbom	yes		no		no	3.16s
✅ YAML	prettier	11	0	0		0	0.71s
✅ YAML	v8r	11		0		0	15.66s
✅ YAML	yamllint	11		0		0	0.97s

Notices

⚠️ Your configuration references items that have been removed from MegaLinter and are ignored: MAKEFILE_CHECKMAKE. See Removed linters to find their replacements.

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@10.0.0 --custom-flavor-setup --custom-flavor-linters PYTHON_BLACK,PYTHON_ISORT,COPYPASTE_JSCPD,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_BETTERLEAKS,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY_SBOM,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository