Why not build on top of existing projects about workalendar HOT 9 CLOSED

hi, @dreispt

The "workdays" project... I've browsed the code, and found it over-complicated to be honest. it's workdays.py module is way too long and complex compared to our "is_workday" method, that works as a charm, using classes that can be extended (a lot of calendars don't use Saturday and Sunday as week-end days, for example, how could we implement that with https://github.com/ogt/workdays/blob/master/workdays.py#L35)?

AFAICT, @nandoflorestan 's project was probably the most interesting to my eyes, because it had very good features about regional calendars, etc. But it was missing week-end computations, for example, and I was not convinced by the dictionary structure returned by its main function (get_holidays()).
Another thing annoying me: calendar not being classes, and thus, not being extendable. The "load" mechanism is based on the location string, that would lead to a quick'n'dirty dynamic loading using https://github.com/nandoflorestan/holiday/blob/master/holiday/__init__.py#L21 the import module. I'd avoid that, personnally.

But, yet again, the "holiday" project is very interesting and it's a great source of inspiration.

from workalendar.

well... as a friend of mine has told me, I may not give a correct reply to your issue.

I think I'll try to contact at least @nandoflorestan to see if anything can be to "join forces" as you said and build something together.

from workalendar.

Thanks for calling me into this discussion!

It's obvious that the projects share a single purpose and that joining forces is exactly what should be done.

workalendar is an extremely interesting project and I wholeheartedly agree with its smart class-based design. Wondering why I didn't come up with the same thing, I conclude I was only scratching my own itch and caring for my own use case.

Though workalendar's design is superior, it does not help in my use case, which is where the following points come from.

First off, I must insist on returning pairs of dates and holiday names, just because my use case involves displaying the holiday names to the end user. So my admiration for workalendar's design and features comes with this wish, that it would cater to my needs, too. Can you be more specific -- what is wrong with a dictionary?

For a couple hours I contemplated returning not a dict but a list of tuples, or an OrderedDict. However, I found that the computation of holiday dates involves mixing fixed holidays with variable ones, and one never really knows their final order before the computation. In other words, a dynamic holiday can end up before or after a static holiday depending on the year. In conclusion, the computation involves storing all holidays and then sorting them; therefore, I might as well just return a dict and leave the ordering to people who need it. My use case does not need sorted holidays and sorting is trivial in Python anyway.

With the class-based design, it is trivial to create methods that return various data structures (as a convenience to the user), ordered or not, but I believe they all should use a main method that returns a dict of date:holiday_name pairs.

So this is the first thing I think workalendar should learn from holiday.

The other interesting feature of the holiday project is dispatch, based on two dimensions: location and scope. If there can be a more elegant solution for the dispatch code, I am all ears; however, again you don't say what exactly is so fundamentally wrong or ugly with it right now.

Choice of scopes is the least clear thing right now. I only know the stock and futures markets may have different holidays in the UK. Also, in Brazil there are "informal" holidays, can you believe this? These are holidays that aren't in the laws, but almost everybody follows them -- a tradition. So the user of the code should be able to specify what answer is desired based on this kind of scope. But I don't know yet the best way to define this. This is very important, though. A library has no value to me if it cannot give an answer that is correct for my use case.

I am very interested in your thoughts about these 2 subjects and hope I can join the workalendar project soon. :)

from workalendar.

hi, @nandoflorestan and thank you for your input.

Can you be more specific -- what is wrong with a dictionary?

There's nothing wrong with dictionaries... but here's my point: we have fixed date holidays and variable holidays. Of course, you need to compute everything before sending the result back from your class or function or whatever... but what happens if a fixed-date holiday and variable holiday happen the same day? How to solve the "clash"? (and yes, it happens).

At the moment, workalendar doesn't make a difference. we return a set of holidays, no more.
From the "is it a workday or not", it's the same. Whatever the cause is (is it a sunday, a variable or a fixed date holiday, we don't care).

But holidays wants to return a dictionary with key == date and value == a label.
Which label is going to be set?... the last one, unfortunately.

DIctionaries are great structures when you want to have one key equals to one and only one value.

And main issue is: dictionaries aren't sorted by default. You may argue: "but sets aren't sorted either". You're right. That's the reason why I've opened #9.

Your usecase is interesting, though ; having a list of holidays that include a label is a convenient way to provide user-friendly information about the given dates.

And you're right: anyway one would need to compute everything first, store into a fully-featured structure and allow anybody to extract the holidays the way they want (sorted, unsorted, etc)

The other interesting feature of the holiday project is dispatch, based on two dimensions: location and scope. If there can be a more elegant solution for the dispatch code, I am all ears; however, again you don't say what exactly is so fundamentally wrong or ugly with it right now.

I'm not a big fan of your way to parse a location string, split into country / region / location and rely on that to load calendars.
I was more going to build Mixins or classes that any calendar class could inherit from and rely on the class name and only the class name. I'm a bit suspicious when it comes to rely on string parsing for this.

Maybe the holidays way is not ugly as I may have seem to say (if you were hurt by my argument, please accept my apologies). It's just that I never feel comfortable with string parsing for extracting crucial data about the calendar type, etc.

At my workplace, we're already thinking about integrating workalendar objects in django applications, and if I had to pick a select list, I'd rather rely on the class name as a key and its unicode representation as a display label (note to self: add a unicode method to my classes).

Anyway, I'm very glad that workalendar has attracted your attention, and I'm really happy that you're getting into this discussion.

I hope we can build the best calendar library in the Python world!

from workalendar.

I'm glad I opened up the discussion, that was the point.
Other potential contributors will appreciate it.

from workalendar.

@brunobord , I see the first point. Can we settle on the list of 2-tuples as the basic data structure then? (Not because the list would be ordered -- it wouldn't -- but because it allows us to represent 2 holidays that fall on a single date.)

I can discuss the second point later, but even if we disagree -- worst case scenario --, it would be a good practice to build dispatch as an independent software layer. For instance, the holiday project could be redefined as dispatch for workalendar.

Cheers!

from workalendar.

is this topic worked out in a way? (i.e., shall we close this issue?)

from workalendar.

Yes, It's OK to close this.

On Fri, Dec 20, 2013 at 8:52 AM, Bruno Bord [email protected]:

is this topic worked out in a way? (i.e., shall we close this issue?)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-30996327
.

from workalendar.

thanks everyone for this interesting debate. live long and prosper.

from workalendar.