[PEAK] Rules clarification

[Sergey Schetinin]

After poking around the code a bit I see that an appropriate
implementation of that seems to be:

@when(implies, (object, type))
def type_implies(s1,s2):
    return implies(s1, (s2,))


On Thu, Feb 28, 2008 at 7:21 AM, Sergey Schetinin <maluke at gmail.com> wrote:
>
> Thanks for your reply.
>   I think it would be reasonable to assume that if the second parameter
>   to <when> is a type it should be treated the same as a tuple with that
>   single value. This should illustrate what I'm talking about:
>
>   from peak.rules import *
>
>   @around(when, (object, type)) # this shouldn't be necessary IMO
>   def when_type(func, type, *args):
>     return when(func, (type,), *args)
>
>   @abstract
>   def x(a):
>     return a
>
>   @when(x, int)
>   def xint(a):
>     return a+1
>
>   assert x(1) == 2
>
>
>
>
>   On Thu, Feb 28, 2008 at 6:56 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
>   > Sorry I didn't reply to this sooner; I meant to think about it before
>   >  replying and then it scrolled out of my immediate view and I
>  forgot about it.
>   >
>   >
>   >
>   >  At 06:47 PM 2/15/2008 +0200, Sergey Schetinin wrote:
>   >  >I've noticed that "when" function accepts anything as it's second
>   >  >parameter (not just tuples),
>   >
>   >  Yes; all that is required is that it be something which can "imply" a
>   >  type tuple (i.e. using the peak.rules.implies() function).
>   >
>   >
>   >
>   >  >  what does this declaration would mean
>   >  >then (maybe nothing and it should throw an exception?)
>   >  >
>   >  > >>> from peak.rules import *
>   >  > >>> @abstract
>   >  >... def test(foo):
>   >  >...     pass
>   >  >...
>   >  > >>> @when(test, int) # <--------- this is what I'm talking about
>   >  >... def test_int(foo):
>   >  >...     print foo
>   >  >...
>   >
>   >  It indeed means nothing.  Whether it should throw an exception is a
>   >  more complex problem.  Right now, the default for testing implication
>   >  between two different types is to say that neither implies the
>   >  other.  This is a sensible default, except for where it's misleading
>   >  in this case.  So I could add a specific rule to catch it and throw
>   >  an exception, but I'm wondering how many such special cases would
>  need adding.
>   >
>   >
>
>
>
>
>
>  --
>   Best Regards,
>   Sergey Schetinin
>
>   http://s3bk.com/ -- S3 Backup
>   http://word-to-html.com/ -- Word to HTML Converter
>
>
>
>  --
>  Best Regards,
>  Sergey Schetinin
>
>  http://s3bk.com/ -- S3 Backup
>  http://word-to-html.com/ -- Word to HTML Converter
>



-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter