[PEAK] Type implications bug

[Sergey Schetinin]

Phillip, can you please commit a fix for
http://www.eby-sarna.com/pipermail/peak/2008-June/002995.html
If you need a test case it's "from peak.context import *"

Also, http://www.eby-sarna.com/pipermail/peak/2008-June/002990.html
needs some attention too, should I forward it to distutils-sig or
something like that?

Thanks.

On Tue, Jul 15, 2008 at 17:58, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:23 PM 7/15/2008 +0200, Alberto Valverde wrote:
>>
>> Hi,
>>
>> I've attached a unit test which blows up peak/rules/indexing.py._get_mro.
>
> Hm.  There are actually two problems here.  First, issubclass() is being
> called on an object that's not a class or type, and that blows up the class
> lookup code.  The second is that isclass(x) isn't being tested before that,
> because direct tests on parameters are assumed to not require prerequisites
> to go first.  In other words, PEAK-Rules assumes that issubclass(x, ...) can
> go before any other test on x.
>
> This can be fixed by removing the predicates.always_testable() rule for
> IsSubclass criteria; then IsSubclass tests will not be moved in front of
> other criteria.  Doing issubclass() on a non-class/type object will still
> blow up, though.
>
> _______________________________________________
> PEAK mailing list
> PEAK at eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/peak
>



-- 
Best Regards,
Sergey Schetinin

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