Yep, I was wondering about irrelevant things, there is no problem in
this case,
actually.
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
Michele Simionato wrote:
> Duncan Booth:
>> Fortunately you have a list of
>> argument names readily available so it shouldn't be too
>> hard to generate unique names to use in their place.
>
> It does not look too simple either. Whereas I can easily
> build valid Python identifiers which are ext
I have uploaded version 0.5 that should fix all the
subtle bugs you pointed out, but there could be others
(I would not be surprised in that case ;).
I will add a test suite for various corner cases tomorrow.
BTW, I cannot decide if exotic function signatures are
a feature or an accident ...
Duncan Booth:
> Fortunately you have a list of
> argument names readily available so it shouldn't be too
> hard to generate unique names to use in their place.
It does not look too simple either. Whereas I can easily
build valid Python identifiers which are extremely unlikely
to clash with any ide
Notice that the decorator module is at version 0.4 and I still consider
it as experimental. The reason why I posted the link here is to get
feedback and it seems I got it ;)
I will upgrade to version 0.5 shortly, fixing the easily fixable bugs
and
documenting what cannot be easily fixed.
Thanks f
Michele Simionato wrote:
> with the following advantages:
>
> 1. one-level of nesting is saved ("flat is better than nested")
> 2. name, docstring and dictionary of the original function are
> preserved;
> 3. the signature of the original function is preserved (this one is
> nontrivial).
>
could ildg wrote:
> I think decorator is a function which return a function, is this
right?
> e.g. The decorator below if from
http://www.python.org/peps/pep-0318.html#id1.
>
> def accepts(*types):
> def check_accepts(f):
> assert len(types) == f.func_code.co_argcount
> def new
