[PEAK] Type implications bug
maluke at gmail.com
Wed Jul 16 01:22:18 EDT 2008
Phillip, can you please commit a fix for
If you need a test case it's "from peak.context import *"
needs some attention too, should I forward it to distutils-sig or
something like that?
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:
>> 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://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter
More information about the PEAK