[PEAK] Re: PEAK-rules question

[PJ Eby]

On Fri, Aug 30, 2013 at 10:59 AM, Sébastien de Menten
<sdementen at gmail.com> wrote:
> Hello,
>
> I have two questions on your great PEAK-rules packages (thanks a lot for it
> !) 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 (pycharm) 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.
>
>  Would you have some trick to avoid this ? I was thinking along in the lines
> of a when_inside decorator working in the following spirit:
>
> [proposal deleted]
>
> In your opinion, is this meaningful/useful ? but also doable ?

Neither.  First, if you put the condition in the code, it's going to
be executed a second time.  About the best you could do here would be
to use a lambda in place of a string, provided that you had a
foolproof way to get the source.  And of course, such a method won't
work unless the source is available, or you can reverse-engineer the
bytecode to a condition.

Either way, it's not something I have sufficient interest in; if you
want syntax highlighting of strings and import detection in your IDE,
it seems the simplest way to fix it is to tell the IDE that the
strings need highlighting and parsing, perhaps via some sort of
pragma.  For example:

    @when(
         gf,
         "condition here"  # pragma: eval
     )

If your tools are built for Python, it seems it would be good for them
to support some limited understanding of dynamic code patterns.  ;-)

(Of course, the actual spelling of the pragma might be simpler, and in
keeping with whatever pragma facilites are already supported by the
tools.)

All that being said, if someone wants to implement the lambda idea, it
is quite possible by registering appropriate methods with the
PEAK-Rules core for parsing the "function" type.  In peak.rules.core,
type and tuple handlers are registered, and in peak.rules.predicates,
a string handler are registered.  So by registering a handler for
lambdas, you could implement that feature yourself.

(Personally, I think it would probably be easier to get the other
tools to recognize certain strings as code, than to reverse-engineer a
condition from a lambda or trying to extract its source, but it's up
to you.)


> 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 do it differently ? My feeling it
> is that it is one of the use of multi-methods ... but it is my first use of
> this concept in a real project.

I don't know how to answer your question because the description is
too abstract.  My feeling is that it depends a lot on why you are
representing these things this way in the first place, and what the
things are.  What sort of operations, sources, and destinations are we
talking about?  What does the system do, and why did you choose this
structure?  Without knowing those things, I can only shrug in reply to
the question.