[PEAK] peak.security weirdness

Phillip J. Eby pje at telecommunity.com
Fri Jan 20 13:02:20 EST 2006


At 12:42 AM 01/20/2006 +0100, Simon Belak wrote:
>First of all a great big thanks for your most informative explanation!
>
>However I still can't help myself not to question why add the implicit 
>rule for self. Is there any other reason besides automatic specialisation 
>when mixing functions and methods as specialisations of a single generic 
>function? Granted, it can be convenient, but it is also a bit "magical", 
>isn't it?

The Python rule is that defining a function in a class makes it available 
as a method for instances of that class and its subclasses.  It never makes 
that function available as a method of *superclasses* -- which is what 
would happen if the subclass restriction were not included.  I don't think 
this is any more "magical" than the usual Python rule.


>What's even worse, doesn't this reduce usability? If I understand 
>correctly, one of the reasons why Python uses explicit self is to enable 
>instances to "borrow" methods from other classes (when conforming to a 
>given protocol). Implicit specialisation makes it impossible to use 
>generic functions in such a context.

Not at all.  In normal Python, you can't borrow a method for a 
non-subclass, you can only borrow a *function*, and you can still do this 
in the generic function case, assuming you can "get to" the function that 
was added.  (For example, if you use a different function name than the 
generic function, so that it can still be accessed by its unique name.)


>And now for something completely different. Is my understanding of 
>evaluation order now correct? All non-parameter symbols are evaluated 
>immediately while expressions are evaluated at each dispatch?

It would be more precise to say that every subexpression is evaluated 
immediately unless it depends on the value of a function argument.  All 
other subexpressions are constant-folded away, except for zero-argument 
function calls, which are assumed to be getters for some dynamic state.

All expressions defined by any rule are computed at most once per dispatch.


>How about tautologies, are they by any chance discarded?

No.  If an expression to be truth-tested ends up as a constant, the test 
still takes place at dispatch time.  A future version of RuleDispatch could 
potentially optimize this away, I suppose.




More information about the PEAK mailing list