(Is that you Joev?)

Thanks, I will make every attempt not to make that mistake again; (I have made it a whopping 38 times already.) I make no secret of the fact that I can not spell to save my life.

a lot
-adverb
to a very great degree or extent; “I feel a lot better”

I really should have done better research on #1, as it seams I missed many things. I knew about PEP 362, but was not up to speed on the work done on it. I thought it was going to be rejected (from early dev chatter back in October). I haven’t kept up much with the dev work since then. It’s good to hear that there is a sandbox implementation which works with annotations. I will try to get back up to speed on this.

On the compiling of .pyc/.pyo files, if you write a custom compiler you can enforce that the __file__ is set to an absolute path. This is what we are currently doing, but without your import extensions and bootstrapping, you still need to compile to the same directory as the .py. I Don’t think you really need two directories on the path, you can have one directory for the .py files, and then as part of the custom import, before doing the compile step, first extend the search to that files directory + say a directory with the python version number. This is they type of hack that is not possible with the current import hook.

As for #4, I think you right that my import stuff will help. You can probably get away with having two entries on sys.path (one for the .py files, the other for the .pyc/.pyo files). You then have a custom handler for the loader that deals with the. py files that knows to write out all .pyc/.pyo files to the other directory. A custom loader for the .pyc/.pyo files would also be needed to set __file__ properly for the exceptions (I think that is all .pyc files need).

Then again, .pyc/.pyo files need a redesign. They really should be merged into a single format and probably contain metadata that specifies what file it was created from so that this is all much simpler.

For Py3K we really need this functionality builtin. Interested on working on a PEP together?

The threading was just an example of a common decorator which does not change the argument spec of the function it decorates, but by decorating it, you loose that argument spec which is used by help, doc generate, and other decorators like those in the functools module.

Peter:

Yes I know about the decorator module, and I have my own version of it. The problem is those calls do not do what this one does:
http://derivin.addr.com/pycon2006/dec1.py

Which is preserve the argument spec of the original function or method. If the origional has ‘def foo(a, b, c=None)’ in module ‘testing’ then I want all that information on the wrapped version preserved (And no Brett, I do not want nor support tuple arguments, they suck).

UPDATE: I AM WRONG. I does exactly what I want!

@clone_definition(threadsafe)
@clone_definition(print_hello)
@decorator.decorator(threadsafe)
@decorator.decorator(print_hello)
def myfunc(a, b, c=None):
   '''documentation'''
   print a, b, c

>>> help(myfunc)
Help on function myfunc in module testing:
myfunc(a, b, c=None)
    documentation

>>> myfunc(1,2,3)
acquiring...
hello
1 2 3
releasing...
>>>

I want the function name, module and arguments to be preserved while still being wrapped.

Simon:

I know about this module and the first function proposed for it was the decorator decorator, which did what I wanted (but in a way thata sometimes crashed, didn’t support default args, and had major problems with tuple arguments).

>>> def dec(f):
...   @functools.wraps(f)
...   def wrap(*args, **kwds):
...     print "Hello"
...     return f(*args, **kwdargs)
...   return wrap
...
>>> @dec
... def foo(a, b, c=None):
...   """doc string"""
...   print a,b,c
...
>>> help(foo)
Help on function foo in module __main__:

foo(*args, **kwds)
    doc string

>>>

Not quite good enough. I want to see my argument names and default args. With the advent of function annotations, this problem will be compounded. Annotations will be used for interesting things like adding strong(ish) typing, argument validation, more interesting functools, WDSL generation (*shiver*), and rich documentation. If adding a pass through decorator removed the annotations, things will break. That will be unacceptable to many people.

Dunno if you mentioned it or not, I got lost in all the ranting.