[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