Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #79454

Re: When to use assert

References (1 earlier) <4d46b9b6-3ab9-45bc-afe9-55da4d0fe76c@googlegroups.com> <54470c17$0$12985$c3e8da3$5496439d@news.astraweb.com> <mailman.15053.1413942836.18130.python-list@python.org> <5447d20c$0$12997$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmpqKUe6Ou3nuNJNc7M8zuOcYK6YvYWWrO5abH3n3yVjTg@mail.gmail.com>
Date 2014-10-22 09:18 -0700
Subject Re: When to use assert
From Dan Stromberg <drsalists@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.15081.1413994712.18130.python-list@python.org> (permalink)

Show all headers | View raw


On Wed, Oct 22, 2014 at 9:01 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Oct 23, 2014 at 2:49 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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 the post-conditions of pretty much anything. Do you
> put these assertions every time you call the function? Every time
> you're depending on its return value? At what point should you stop
> writing Python code and start using a language with a lot more
> boilerplate and checking (I believe Haskell fits that, though I'm not
> overly familiar with the language)?

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.

I think you're in good company - a lot of developers don't use assertions much.

I like assertions, because they tend to stop bugs pretty quickly.  If
you have 3 functions, one calling another calling another, assertions
in each can keep you from having to backtrack among them when
debugging, instead going directly to the problem's source.

> This is the job of a test suite.

Test suites are great, and I can't really question your reliance on
them.  I love having lots of automated tests.  But for the reason I
described above, I still like having lots of assertions.

> You don't pepper your code with
> assertions to the effect that "I just pushed something onto my queue,
> it should now have this item in it"; you create a test case for it,
> and verify your function there. In the rest of the code, you trust
> that your test suite passes, and don't waste time with assertions.

I wouldn't test that a value was added to a queue immediately after
adding it.  That's excessive, and may even require an abstraction
violation.

But if, for example, I have a string with 3 known-good values, I'll
if/elif/elif/else, and make the else raise an AssertionError.  The
assertion should never fire, but if the code changes, it could, and if
there's a typo somewhere, it could then too.

> Or is that insufficiently paranoid?

With good tests, you're probably fine.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: When to use assert Anton <anton.schattenfeld@gmail.com> - 2014-10-21 00:48 -0700
  Re: When to use assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-22 12:44 +1100
    Re: When to use assert Chris Angelico <rosuav@gmail.com> - 2014-10-22 12:53 +1100
      Re: When to use assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-23 02:49 +1100
        Re: When to use assert Chris Angelico <rosuav@gmail.com> - 2014-10-23 03:01 +1100
        Re: When to use assert Dan Stromberg <drsalists@gmail.com> - 2014-10-22 09:18 -0700
          Re: When to use assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-24 18:49 +1100
            Re: When to use assert Chris Angelico <rosuav@gmail.com> - 2014-10-24 19:18 +1100
              Re: When to use assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-26 20:39 +1100
                Re: When to use assert Chris Angelico <rosuav@gmail.com> - 2014-10-26 20:51 +1100

csiph-web