Use setdefault instead of hard-coding observed_rule and observed_since

[BossColo]

Proposed change

Instead of calling super().init() from countries with hard-coded values for override_rule and override_since, use kwargs.setdefaults() to add a value if one isn't passed in. This allows for users to set their own override_rule and override_since if desired.

Type of change

• New country/market holidays support (thank you!)
• Supported country/market holidays update (calendar discrepancy fix, localization)
• Existing code/documentation/test/process quality improvement (best practice, cleanup, refactoring, optimization)
• Dependency update (version deprecation/upgrade)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (a code change causing existing functionality to break)
• New feature (new python-holidays functionality in general)

Checklist

• I've followed the contributing guidelines
• I've added references to all holidays information sources used in this PR
• The code style looks good: make pre-commit command generates no changes
• All tests pass locally: make test, make tox (we strongly encourage adding tests to your code)

[BossColo]

Sorry about the force pushes. Didn't realize what I was doing when I clicked the Update branch button. Been a while since I used GitHub.

[BossColo]

Rebased to resolve merge conflicts.

[arkid15r]

Hi @BossColo,
thank you for the PR!

The implementation is clean and pretty straightforward, I have a question about the motivation though: do you have an example when a user would need to override those values?

I agree, it may be great to have the proposed kwargs.setdefault approach implemented from the user perspective.
The point was in keeping PH a source of truth for holiday dates (including observances). This type of flexibility might discourage people submitting fixes for incorrect observance rules -- why bother when you can just override it, right?

Anyway, I'd like to hear more opinions here as I'm not convinced this is beneficial in a long term run.

@KJhellico, @PPsyrius could you also look into this?

Thank you!

[BossColo]

Hi @BossColo, thank you for the PR!

The implementation is clean and pretty straightforward, I have a question about the motivation though: do you have an example when a user would need to override those values?

I agree, it may be great to have the proposed kwargs.setdefault approach implemented from the user perspective. The point was in keeping PH a source of truth for holiday dates (including observances). This type of flexibility might discourage people submitting fixes for incorrect observance rules -- why bother when you can just override it, right?

Anyway, I'd like to hear more opinions here as I'm not convinced this is beneficial in a long term run.

@KJhellico, @PPsyrius could you also look into this?

Thank you!

My personal use case stems from the fact that I work for a Canadian company with a worldwide footprint. The company has decided that for all jurisdictions, we will use the SAT_SUN_TO_NEXT_MON rule, regardless of the country in question. So if I want to use this library for US holidays, I have to override the __init__ method for the US class.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[arkid15r]

My personal use case stems from the fact that I work for a Canadian company with a worldwide footprint. The company has decided that for all jurisdictions, we will use the SAT_SUN_TO_NEXT_MON rule, regardless of the country in question. So if I want to use this library for US holidays, I have to override the init method for the US class.

Thanks for providing more context, @BossColo. It may be weird but totally legit use case. Apparently, sometimes the library doesn't have to be the source of truth for holidays data.

Thank you for the clean PR and your first contribution!

[BossColo]

My personal use case stems from the fact that I work for a Canadian company with a worldwide footprint. The company has decided that for all jurisdictions, we will use the SAT_SUN_TO_NEXT_MON rule, regardless of the country in question. So if I want to use this library for US holidays, I have to override the init method for the US class.

Thanks for providing more context, @BossColo. It may be weird but totally legit use case. Apparently, sometimes the library doesn't have to be the source of truth for holidays data.

Thank you for the clean PR and your first contribution!

Thank you for the kind words, and for the fantastic library!