Re: Type implications bug

"Sergey Schetinin" <[email protected]>
Newsgroups gmane.comp.python.peak
Message-ID <[email protected]>
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-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> 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
> [email protected]
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.