On 9/23/2010 3:26 PM, Guido van Rossum wrote:
On Thu, Sep 23, 2010 at 11:52 AM, Antoine Pitrou<solipsis@pitrou.net> wrote:
On Thu, 23 Sep 2010 14:39:01 -0400 Terry Reedy<tjreedy@udel.edu> wrote:
If I were writing a class intended to implement an particular ABC, I would be happy to have an automated check function that might catch errors. 100% testing is hard to achieve.
How would an automatic check function solve anything, if you don't test that the class does what is expected?
Again, this is exactly the argument for compile-time type checking, and it is routinely pointed out that it is mostly useless.
That may be the party line of dynamic-language diehards, but that doesn't make it true. There are plenty of times when compile-time checking can save the day, and typically, the larger a system, the more useful it becomes.
Sometimes you surprise me with your non-dogmatic practicality. I do hope, though, that you continue to reject C-like braces {;-}.
Antoine, can you back off your attempts to prove that the proposed feature is useless and instead help designing the details of the feature (or if you can't or don't want to help there, just stay out of the discussion)?
Yes, let the cat scratch his itch and see what he produces. Since unittests have been brought up, I have a idea and question. Can this work? Split the current test suite for a concrete class that implements one of the ABCs into concrete-specific and ABC-general portions, with the abstract part parameterized by concrete class. For instance, split test/test_dict.py into test_dict.py and test_Mapping.py, where the latter has all tests that test compliance with the Mapping ABC (or whatever it is called) and the former keeps all the dict-specific extension tests. Rewrite test_Mapping so it is not dict specific, so one could write something like class MyMapping(): "Implement exactly the Mapping ABC with no extras." ... if __name__ == '__main__': from test import test_Mapping as tM tM.concrete = MyMapping tM.runtests() This is similar to but not the same as splitting tests into generic and CPython parts, the latter for reuse by other implementations of the interpreter. (For dicts, test_dict.py could still be so split, or a portion of it made conditional on the platform.) This idea is for reuse of tests by other implementations of ABCs, whatever interpreter implementation they run under. The underlying question is whether ABCs are intended to be an integral part of Python3 or just an optional extra tucked away in a corner (which is how many, including me, still tend to view them)? If the former, then to me they should, if possible, be supported by a semantic validation test suite. In a way, I am agreeing with Antoine's objection that signature validation is not enough, but with the opposite suggestion of extend rather than reject Tarek's idea of providing auto test tools that make writing and using ABCs easier. -- Terry Jan Reedy