Avoid circular import in registry

[sevdog]

In current version (3.0.0) there is a circular import involving registry.py which makes interpreter to fully load the whole library everytime a calendar is used.

The circular may be summarized like this: registry.py -> <continent-module> -> <country-cal>.py -> registry.py. This however works thanks to how interpreters read the code (ie: iso_register decorator is defined before importing every country in registry.py, so it works).

To test this try:

# see https://docs.python.org/3.5/library/trace.html
from trace import Trace
tracer = Trace() 
# make run a simple import for a single country
tracer.run('from workalendar.europe.italy import Italy')
res = tracer.results() 
# print results
res.write_results(coverdir='.', summary=True)

You will see that to load a single calendar the whole library was loaded. This may be fine in some cases, but its a waste of execution time and memory.

A kind of lazy registry may perform better. However some kind of mapping and a bit of logic are required for this to be accomplished.

[brunobord]

Interesting. I suspected that something was wrong when I was working on this global registry but I couldn't get my head around it.
What do you think would be the best way to split these gracefully?

[sevdog]

This is not an easy guess.

Maybe mappings could be defined inside a JSON or in a config dict, using a string, then importlib could be used to load the right element (in a way like django does with its import_string method. This approach may be less pythonic (cause registration would be done by via "config" file instead then by decorator) and could bring some annoiyng problem when a class is moved from one file the an other, but should drastically reduce the number of module loads.

ATM this was my first idea, I am not saying its the best option.

[brunobord]

back on the saddle on this. I need some fresh ideas, let's see what can emerge, now.

[brunobord]

I think I've got something in this branch: https://github.com/peopledoc/workalendar/compare/288-new-registry

Invoking @Natim because he was the one who implemented the ISO register in the first place. Do you remember why you've used OrderedDict? Does it really matter to remember the order of the items were inserted?

[Natim]

You can probably get rid of it