> b) Having an assumption match might not always mean "==". Consider C > booleans for instance, where "attr=True" should map to checking whether > "self.attr != 0". However one could argue that one should then create a > Python property that converts attr to a Python boolean object; so this > might not hold; but having manual run-time-code just seems more > flexible... Still this, aspect can be dropped from assume, it can still > play the other roles.
I found a better example. Consider this: cdef ndarray(c_contiguous=True) arr = x Here, c_contiguous is a "virtual field" which is not present in itself, only present for the benefit of inlineable code. However, you cannot check whether an array is c_contiguous just by checking the contents of a field, rather you want to do if x.flags.c_contiguous is not True: raise AssumptionError(...) Ok, so you could have modified the syntax slightly, to do cdef ndarray(flags.c_contiguous=True) arr = x but this quickly gets hairy... The point here is: - You can do arbitrarily complex assumptions... - and stuff the "result" of the assumption into a simple "virtual field" that is only available when operating under the assumption. I.e: cdef Arr(does_very_complex_assumption_hold=True) arr = x # __assume__ is called under to hood, and notices that # it should check a very complex assumption and raise # exception otherwise arr.do_something() # This is inlined to very fast code because the # inlineable implementation of do_something simply # has a check for whether arr.does_very_complex_assumption_hold # is True -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
