On 4/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
You summarize the differences clearly. Let's agree to disagree. I think that having to have an abstraction marker on the class *and* on the abstract methods is asking the user to repeat (nearly) the same information twice, and I really don't think that a (partially) abstract class needs to be re-marked as abstract.
OK. I still believe that this slight flaw is worth the benefit of def time checks, but accept your judgement that the use cases I have in mind are not common enough to justify it. Consider my proposal withdrawn. I find it hard to believe that the definition-time error saves you
much development time at all compared to a instantiation-time error. Others have already responded to your attitude towards unit tests -- if your unit tests take 10 minutes to run, you're doing something else wrong. May I suggest you read this: http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html
Sigh. I think unit tests are great. I write unit tests for all of my code. I have a script that runs all the unit tests on our development branch overnight and emails me about the things that fails. I'm not motivated by a dislike of unit-tests. If anything, I am too much a believer in testing which is why I advocated the option to have more testing facilities (i.e., def time tests). I think having more options available for testing is a good thing and I don't understand the vehement objections people have to anything that vaguely resembles static checks. Thanks, -Emin
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
