Possible PEP: Improve classmethod/staticmethod syntax
Jeff Epler
jepler at unpythonic.net
Wed Jun 4 11:59:50 EDT 2003
On Wed, Jun 04, 2003 at 10:21:07AM -0500, Skip Montanaro wrote:
>
> gca> Since decorators are in a dictionary, in what order should they be
> gca> applied? I though item extraction from a dictionary was, basically,
> gca> unordered.
>
> Correct. The advantage of a dictionary is that the individual elements can
> be more complex. For the pre- and post-condition stuff this works well. To
> use lists there you have to extend list constructor syntax somehow, as I
> used in my original message:
>
> def foo(...) [pre=foo_pre, post=foo_post]:
> <normal code here>
>
> You could also use strings:
>
> def foo(...) ['pre=foo_pre', 'post=foo_post']:
> <normal code here>
>
> The compiler would presumably split them at the '=' and eval() the right
> hand side where necessary to get at the actual value.
Why not use
def foo(...) [pre(foo_pre), post(foo_post)]
where pre(x) returns a callable that will add the x precondition to its
argument? For instance,
class pre:
def __init__(self, precondition):
self.precondition = precondition
def __call__(self, f):
return add_precondition(f, self.precondition)
as far as I understand the proposed syntax, the items inside the [...]
are Python expressions (which must evaluate to callable objects), not
just identifiers.
One other message in the thread asked, "what if you want to turn off
pre/postcondition checking" (paraphrase). I don't see why you wouldn't
be able to change 'pre's behavior before the 'def foo' block, since it's
just any callable. Something like
if do_preconditions:
from preconditions import pre, post
except:
pre = post = lambda x: x
Jeff
More information about the Python-list
mailing list