On 11/11/12 17:18, Steven D'Aprano wrote: > but that leaves you with the next two problems: > > 2) Fixing the assert still leaves you with the wrong exception. You > wouldn't raise a ZeroDivisionError, or a UnicodeDecodeError, or an IOError > would you? No of course not. So why are you suggesting raising an > AssertionError? That is completely inappropriate, the right exception to > use is TypeError. Don't be lazy and treat assert as a quick and easy way > to get exceptions for free.
I'd say that it depends on whether the dictionary/kwargs gets populated from user-supplied data (whether mail, a file, direct input, etc), or whether it's coder-supplied. I like to think of "assert" as a "hey, you bone-headed programmer, you did something that violated conditions for using this code properly!" and as such, entirely appropriate to use in the coder-supplied case. This rolls into... > 3) Asserts are not guaranteed to run. Never, never, never use assert to > test function arguments supplied by the caller, because you have no > control over whether or not the asserts will even be called. where, once the programmer is satisfied that the code runs, meeting all the appropriate tests/assertions, the assertions can then be turned off (if one really cares that much; can't say I've done it more than a couple times, mostly out of experimentation/testing to see if it made any grave difference in performance). I think you intend this in your > Or for testing things which "can't possibly fail". But of > course, since what can't go wrong does, you sometimes still want > to test things. -tkc -- http://mail.python.org/mailman/listinfo/python-list
