Kevin Dangoor wrote:
Though in the long run I would still like to see true invariants.
I'm not sure how we'd implement the features we have with true
invariants. What this module offers at least makes the new function
masquerade very convincingly as the original.
My idea from a previos message:
The way I would approach this problem is to decouple our controller
form CherryPy altogether and have decorators dynamically build the
actual implementation.
This would also allow changing "HTTP layer" if anybody wishes to do
so.
I do think that using decorator() from this library will make our
decorators much nicer to read *and* give them the original signature.
However, the one thing it doesn't do is let as add additional
parameters, which is something we need to be able to do. Right now,
decorator() takes a function with a signature (func, *args, **kw).
Maybe we should extend it to allow additional named arguments which
are automatically not passed to the enclosed function.
Wouldn't this be more suited for a separate decorator? Is a decorator
even needed? As long as there are few and well defined conversions
wouldn't lambdas be better (more explicit)?
Simon
