Steven D'Aprano wrote: > On Mon, 15 Jan 2007 21:01:35 -0600, Ron Adam wrote: > > >> There have been times where I would like assert to be a little more >> assertive >> than it is. :-) >> >> ie.. not being able to turn them off with the -0/-00 switches, and having >> them >> generate a more verbose traceback. > > If you want something more verbose, you have it: > >>>> assert False, "verbose traceback" > Traceback (most recent call last): > File "<stdin>", line 1, in ? > AssertionError: verbose traceback > > If you want something that won't be turned off by -O, you maybe need to > write your own: > > def assert_(condition, msg=""): > if not condition: > raise AssertionError(msg) > >> Maybe have an alternative 'warn' as an alternative debugging version that >> could >> be set to ignore, soft (print to log), and hard (raise an error). > > Check out the warnings module.
Yes, I know it's there. It just seems like assert and warn() overlap currently. Assert doesn't quite fill warn()'s shoes, and warn() isn't as unassertive as assert when it's turned off. A warn statement could be completely ignored and not even cost a function call when it's turned off like assert does now. I don't think it does that currently. Isn't there always some overhead when using the warn() function. Or is there some magic there? An if-raise is just as fast as assert when evaluating as True, so there's no speed advantage there unless you have a large percentage of raises. But it does looks a lot nicer when you want a short positive test, verses a longer negative test with a raise stuck on it. But I think the developers would not consider this to be a big enough matter to be worth changing. So I'll continue to ignore warn(), and also continue to be un-assertive in my python code. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list