[GRASS-dev] temporal framework currently not working on windows

Sören Gebbert soerengebbert at googlemail.com
Thu Dec 4 02:06:42 PST 2014


Hi Glynn,
thanks a lot for this excellent explanation.

Best regards
Soeren

2014-11-27 18:59 GMT+01:00 Glynn Clements <glynn at gclements.plus.com>:
>
> Sören Gebbert wrote:
>
>> > I would like to better understand, this point...
>> > Why the decorator must_be_open  it seems to work so far?
>> > which is the difference between @must_be_open[0] and @mdebug[1]?
>> > Any Ideas?
>>
>> Unfortunately i have no idea. I did not found good information about
>> when and how exactly these decorators are processed.
>>
>> So my guess was that (because of the backtrace) the decorator function
>> is somehow analyzed at import time and the messenger process gets
>> started.
>
> A function used as a decorator is invoked when the decorated function
> is defined, which is usually at import time.
>
> The code:
>
>         @decorator
>         def foo():
>             pass
>
> is equivalent to
>
>         def foo():
>             pass
>         foo = decorator(foo)
>
> Whether this poses a problem depends upon exactly *what* the decorator
> does.
>
> Typical decorators simply return a closure, i.e. a local function
> which, when called, calls the function being decorated. This situation
> is usually harmless, as nothing significant happens until the
> decorated function is actually invoked.
>
> As a general rule, modules shouldn't do anything substantial on
> import. If you're using decorators, this typically means that the
> decorators shouldn't do anything substantial, as they'll be called on
> import. Any work should be deferred until the decorated function is
> called (i.e. it goes inside the local function, not in the body of the
> decorator).
>
> --
> Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list