Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #33152
| Date | 2012-11-11 18:21 -0600 |
|---|---|
| From | Tim Chase <python.list@tim.thechases.com> |
| Subject | Re: List comprehension for testing **params |
| References | <50a0258f$0$21241$ba4acef3@reader.news.orange.fr> <50a03233$0$21756$c3e8da3$76491128@news.astraweb.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3566.1352679640.27098.python-list@python.org> (permalink) |
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
List comprehension for testing **params Cantabile <cantabile.03@wanadoo.fr> - 2012-11-11 23:24 +0100
Re: List comprehension for testing **params Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-11 15:56 -0700
Re: List comprehension for testing **params Tim Chase <python.list@tim.thechases.com> - 2012-11-11 16:49 -0600
Re: List comprehension for testing **params Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-11 23:18 +0000
Re: List comprehension for testing **params Tim Chase <python.list@tim.thechases.com> - 2012-11-11 18:21 -0600
Re: List comprehension for testing **params Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-12 07:32 +0000
Re: List comprehension for testing **params Terry Reedy <tjreedy@udel.edu> - 2012-11-11 18:37 -0500
Re: List comprehension for testing **params Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-11 23:41 +0000
Re: List comprehension for testing **params Cantabile <cantabile.03@wanadoo.fr> - 2012-11-12 00:53 +0100
Re: List comprehension for testing **params Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-11-12 11:48 +0100
Re: List comprehension for testing **params Cantabile <cantabile.03@wanadoo.fr> - 2012-11-12 23:25 +0100
csiph-web