On Sun, Oct 26, 2014 at 8:39 PM, Steven D'Aprano
wrote:
> In the absence of correctness proofs for your code, anything you do (unit
> tests, assertions, regression tests, etc.) is just a statistically sampling
> of all the potential paths your code might take, hoping to capture bugs. As
> any stat
Chris Angelico wrote:
> On Fri, Oct 24, 2014 at 6:49 PM, Steven D'Aprano
> wrote:
>> addresses = [get_address(name) for name in database]
>> assert all(address for address in addresses)
>> # ... much later on ...
>> for i, address in enumerate(addresses):
>> if some_condition():
>> ad
On Fri, Oct 24, 2014 at 6:49 PM, Steven D'Aprano
wrote:
> addresses = [get_address(name) for name in database]
> assert all(address for address in addresses)
> # ... much later on ...
> for i, address in enumerate(addresses):
> if some_condition():
> addresses[i] = modify(address)
>
Dan Stromberg wrote:
> I like to use assertions and "if cond: raise ValueError('foo')" a lot.
>
> I think Eiffel may be the poster-child for a language with
> pre-conditions, post-conditions and assertions.
Yes. I don't think Eiffel is the only language with explicit support for
testing invarian
On Wed, Oct 22, 2014 at 9:01 AM, Chris Angelico wrote:
> On Thu, Oct 23, 2014 at 2:49 AM, Steven D'Aprano
> wrote:
>> Chris Angelico wrote:
> I agree that the assert is preferable to the comment. But maybe my
> level of paranoia is just lower than most people's, as I wouldn't
> bother checking th
On Thu, Oct 23, 2014 at 2:49 AM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> And at that point, the assertion is redundant, on par with:
>>
>> a = len(seq)
>> assert isinstance(a, int)
>>
>> because you shouldn't have to assert what's part of a function's
>> guarantee.
>
> That depends on
Chris Angelico wrote:
> On Wed, Oct 22, 2014 at 12:44 PM, Steven D'Aprano
> wrote:
>> def do_something(instance_or_id):
>> instance = Model.get(instance_or_id)
>> assert isinstance(instance, Model)
>> # Code that assumes that instance is an object of type Model
>>
>>
>> That means tha
On Wed, Oct 22, 2014 at 12:44 PM, Steven D'Aprano
wrote:
> def do_something(instance_or_id):
> instance = Model.get(instance_or_id)
> assert isinstance(instance, Model)
> # Code that assumes that instance is an object of type Model
>
>
> That means that the logic for what is acceptable
Anton wrote:
> I use ORM and often need to write a function that either takes an id of
> the record or already loaded model object. So I end up writing a piece of
> code like below:
>
> def do_something(instance):
> if isinstance(instance_or_id, int):
> instance = Model.get(instance)
On Saturday, November 16, 2013 11:35:50 PM UTC-8, Steven D'Aprano wrote:
> The question of when to use the assert statement comes up occasionally,
>
> usually in response to somebody misusing it, so I thought I'd write a
>
> post describing when and why to use assertions, and when not to.
>
>
On 2013-11-18 09:50, Oscar Benjamin wrote:
> If the program is invoked from a terminal I would probably go with
> 'import pdb; pdb.set_trace()' rather than 'assert 0'. Then you can
> check much more than whether or not the code is being executed.
> It's a bit more to type but I type it so often tha
On 18/11/2013 09:50, Oscar Benjamin wrote:
On 17 November 2013 13:33, Roy Smith wrote:
So, I stick "assert 0" in the code an re-run the program to see if I get
an AssertionError. If I do, then I know the code is being run. If I
don't then I know it's not. Either way, I know more about what'
On 17 November 2013 13:33, Roy Smith wrote:
>
> So, I stick "assert 0" in the code an re-run the program to see if I get
> an AssertionError. If I do, then I know the code is being run. If I
> don't then I know it's not. Either way, I know more about what's going
> on than I did before. Once I
On 17/11/13 13:33, Roy Smith wrote:
Every once in a while, I'll get into a situation where something is
happening that I just can't understand. If a given pice of code is
being called, there's NO WAY the program should be exhibiting the
behavior it's exhibiting. But, there's also NO WAY that p
On Sun, 17 Nov 2013 06:50:56 -0600, Tim Chase wrote:
> On 2013-11-17 07:35, Steven D'Aprano wrote:
>> py> x = 23
>> py> assert x > 0, "x is not zero or negative"
>
> This is the worst way to use an assertion: with a misleading message
> ;-)
D'oh!
Sorry about that.
--
Steven
--
https://m
In article <528871d5$0$29975$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> * Don't use assert for any error which you expect to recover from.
> In other words, you've got no reason to catch an AssertionError
> exception in production code.
Which leads to another reason for u
On 2013-11-17 07:35, Steven D'Aprano wrote:
> py> x = 23
> py> assert x > 0, "x is not zero or negative"
This is the worst way to use an assertion: with a misleading
message ;-)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
The question of when to use the assert statement comes up occasionally,
usually in response to somebody misusing it, so I thought I'd write a
post describing when and why to use assertions, and when not to.
For those who aren't aware of it, Python's "assert" checks a condition,
if it is true it
18 matches
Mail list logo
