[PEAK] PEAK-rules : possible improvements to @when and use case for peak rules

Sébastien de Menten sdementen at gmail.com
Sat Aug 31 02:19:25 EDT 2013


Hello,

I have two questions on PEAK-rules where I would more than happy to have
your opinion/advice.

First the simple one: when using the @when(multimethod_function, "condition
in a string") decorator, i find the "condition in string" syntax slightly
annoying as it is not recognised by the IDE or other code inspector (flake,
etc). For the IDE point, it is not very readable as there is not syntax
coloring and the autocompletion feature (and other refactoring features)
does not work ideally. For the code inspector, it detects falsely that some
imports are unused as they are in fact only used in the string.

 Could there be an alternative? I was thinking along in the lines of a
when_inside decorator working in the following spirit:

 from peak.rules import when, abstract

@abstract
def foo(a, b):
    pass

@when(foo, "a>4 and b<56")
def foo(a, b):
    "This function does blabla"

    for i in range(5):
        print i


@*when_inside*(foo)  # this would be equivalent to the previous definition
def foo(a, b):
    "This function does blabla"
    *a>5 and b<56*     # the condition that normally is the 2nd argument of
when is the first line of code (maybe with an "assert a>5 and b<56" if it
helps)

    for i in range(5):
        print i

*@foo.when*     # this would be even simpler and still equivalent to the
previous definition
def foo(a, b):
    "This function does blabla"
    *a>5 and b<56*     # the condition that normally is the 2nd argument of
when is the first line of code (maybe with an "assert a>5 and b<56" if it
helps)
     for i in range(5):
        print i

The decorator would thus extract and analyse the first code line of the
function (maybe using the meta package (https://pypi.python.org/pypi/meta)
with meta.dump_python_source(meta.decompile(foo.func_code)).split("\n")[1]
to get it)) to get the condition.
In your opinion, is this meaningful/useful ? but also doable ?

My second question is related to the use case for peak rules.
I am using peak-rules in a project essentially to replace standard object
methods in a system with a lot of composition of objects with inheritance.
So I have a class Operation which instances have two attributes which are
instances of two other classes Source and Destination. So the "abstract"
class looks like:
Class Operation:
            source = None (but should be an instance of Source)
            destination = None (but should be an instance of Destination)
then I can subclass Operation to add new attributes/meaning for the class
and the same for Source and Destination.
After that, I have an engine that must interpret (=do calculation on) the
Operation with its Source and Destination and the interpretation is
dependent on the 3 objects (operation, source and destination).
I use peak.rules to dispatch to the correct algorithm in function of the
conditions like:
@abstract
def interpret(operation):
    pass

@when(interpret, “isinstance(operation, SubOperationOfTypeZ) and
isinstance(operation.source, SubTypeWOfSource) and
operation.source.date_of_creation.month < 5”)
def interpret(operation):
    return “blabla”

Is this usage of peak.rules OK ? would you use a different pattern ? My
feeling it is that it is one of the use of generic functions methods ...
but i have no practical experience with them.

Sebastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20130831/158baf7d/attachment.html


More information about the PEAK mailing list