[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grass-dev
Subject:    Re: [GRASS-dev] temporal framework currently not working on windows
From:       Glynn Clements <glynn () gclements ! plus ! com>
Date:       2014-11-27 17:59:59
Message-ID: 21623.26271.851703.428028 () cerise ! gclements ! plus ! com
[Download RAW message or body]


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@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[prev in list] [next in list] [prev in thread] [next in thread]