Make it possible to use multiple calendar settings in the same app. about fiscalyear

[pmav99]

I would suggest to completely avoid globals if possible. They do make it harder to test things etc.

[adamjstewart]

It is actually currently possible to do this using the fiscal_calendar context manager. See https://fiscalyear.readthedocs.io/en/latest/advanced_usage.html#temporarily-changing-the-fiscal-calendar

[pmav99]

I am probably at fault, since I mixed two different issues here.

1. I agree that you can use the context manager, even though i am not sure an API like this can scale if you have multiple settings. It feels rather error-prone.

2. Regardless of the previous point, changing how existing objects behave is IMHO not optimal. IMHO changing the setting should only affect new objects. Again, I don't have a strong opinion for this, since in my current use case I will only need to set the settings once.

[adamjstewart]

That's true, we could redesign the API so that things like START_YEAR, START_MONTH, and START_DAY are attributes of every single object we create. Honestly, when I was designing this, I assumed that the majority of people would be working with a single fiscal calendar, and that it would be pretty infrequent that you would have to mix and match fiscal calendars. In reality, this might be more common than I expected.

Do you know of any other Python libraries that allow you to change global variables? It would be interesting to compare my implementation to how others do it. I'm not opposed to changing it to what you propose, but I don't want to change it without a good reason, and I want to make sure I'm changing it in a way that will be stable and maintainable.

[galenseilis]

I could see some statistical forecasting products breaking with globals such as START_YEAR, START_MONTH, and START_DAY. Easy to avoid if you know about these globals, but could trip the occasional person.