decorators vs GIL

[Christopher T King]

On Tue, 10 Aug 2004, Daniel Dittmar wrote:

> Christopher T King wrote:
> > The real reason behind the GIL is that the Python interpreter is not
> > re-entrant; it keeps internal state in a global structure
> 
> Another reason is reference counting, which must be synchronized.

Forgot about that; a global reference count lock might work well, but this
could negatively impact performance in the case of things like argument
tuples.  Perhaps internal objects that are guaranteed to be thread-local
can skip the reference-count-locking step, but I'm not sure how many (if
any) objects can guarantee this.