On 02/20/2014 10:28 PM, Steven D'Aprano wrote:
On Thu, Feb 20, 2014 at 09:44:57PM +0100, spir wrote:
But I would like to be able to add an error type to assertions (in addition to the optional message). This is particularly useful for people (like me) who systematically check func inputs (for client debugging comfort), using assert's. Then your code is systematically broken, and badly so.
Why do you speak _that_ negatively? (or should I say: _that_ violently?) And this, maybe not _that_ logically? Do you own the (copy)rights on proper usage of assert's?
All anyone needs to do to disable your checking is pass -O to the Python interpreter.
assert is not a short-cut for lazy programmers to avoid having to write an explicit "if cond: raise SomethingAppropriate(message)". Assertions have specific uses. You should read this post I made last November:
https://mail.python.org/pipermail/python-list/2013-November/660401.html
I think you are wrong, at least in this very case. Assert's for me are a debugging tool (or maybe more generally a tool for improving reliability). Such checks help finding errors and correcting them (thank to hopefully clear error messages), with a higher chance these corrections happen before "too late", meaning before users pay for our bugs. What else is the proper usage of assertions? If not checked on function input, either with assert's or an if-raise combination, execution will break anyway, just later (later in time, and slightly further in code), because some input variable's value or type is wrong. Assert's placed that way are not strictly necessary (it's like duck typing: you don't need to check), instead they're a helpful tool for all users of your "service". def average (numbers): n = len(numbers) assert n != 0, "Cannot compute average of 'zero number'.", ValueError return sum(numbers) / n On the proposal: having a correct error type instead of "AssertionError" just helps a bit making the error report clearer for developpers. I note in your post that, according to you, "assertions should be used for" (among other cases): "* checking contracts (e.g. pre-conditions and post-conditions);" This is precisely what I do (pre-conditions). If you don't use assert's for checking assertions which are logical truths if the code is correct, then what for? [Side-note: I do not use here assertions for exception handling (properly speaking) at all; instead for catching errors (properly speaking). It's just that, in python and a long list of other languages, there is a complete confusion between exceptions (which belong to the app's logic, but need to be processed specially) and errors (which don't, and are our fault and our problem). Is this topic clear?] d