3 ms·
I think the key word here is "assumption." zope.interface doesn't enforce its contracts by default; one must explicitly invoke verifyObject() to verify the inva
by MostAwesomeDude 15y ago
I think the key word here is "assumption." zope.interface doesn't enforce its contracts by default; one must explicitly invoke verifyObject() to verify the invariants and interfaces of a given object. But, for speed, verifyObject() is usually omitted in interface-heavy applications. (I admit that my personal projects always verifyObject(), but only for rigorous plugin validation.)
- irahul 15y agoThe waters are murkier here. Apart from checks, you also have @transform_args(a=lambda x: x*x) def foo(a): pass This isn't validation and can't be turned off. The idea behind the project was the function should concentrate on logic and validations should happen declaratively. If the `verifyObject` sort of call comes inside the function, it impacts the declarative goal. The current validators throw Exception by default. They can be optionally take an `error_handler` to which they pass the errors. Bringing in inside the function will mean manually accumulating the errors from various validators. Also, these validators are mostly for conditions which must be met. Say you are writing a sqrt function, then the pre-condition is the number shouldn't be negative and that isn't something that can be turned off. I don't know how zope.interface works but this isn't supposed to be optional validation. It is basically about taking the manual checks from inside the function to above the function with convenient declarative syntax.
- MostAwesomeDude 15y agoAh, I see. You should definitely check out zope.interface; it's a different approach to a similar problem. This is quite cool, though. Good work!