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

Groups > comp.lang.python > #62541 > unrolled thread

cascading python executions only if return code is 0

Back to article view | Back to comp.lang.python

Contents

  cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 15:37 -0300
    Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 14:17 -0500
      Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-22 19:31 +0000
        Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 15:05 -0500
          Re: cascading python executions only if return code is 0 Cameron Simpson <cs@zip.com.au> - 2013-12-23 08:39 +1100
            Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 16:53 -0500
              Re: cascading python executions only if return code is 0 Cameron Simpson <cs@zip.com.au> - 2013-12-23 09:11 +1100
              Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-22 22:10 -0500
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:22 +1100
              Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 03:43 +0000
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:45 +1100
              Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 03:54 +0000
              Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:59 +1100
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 16:10 -0300
      Re: cascading python executions only if return code is 0 Ned Batchelder <ned@nedbatchelder.com> - 2013-12-22 14:49 -0500
        Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 00:08 +0000
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 16:35 -0300
        Re: cascading python executions only if return code is 0 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-23 13:30 +1300
    Re: cascading python executions only if return code is 0 Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-22 14:27 -0800
      RE: cascading python executions only if return code is 0 Frank Cui <ycui@outlook.com> - 2013-12-22 19:14 -0300
      Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 09:51 +1100
      Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-22 23:02 +0000
        Re: cascading python executions only if return code is 0 Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-22 15:57 -0800
          Re: cascading python executions only if return code is 0 Ned Batchelder <ned@nedbatchelder.com> - 2013-12-23 07:27 -0500
          Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 12:44 +0000
    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 00:25 +0000
      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 20:24 -0500
        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 12:35 +1100
        Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-23 13:33 +1100
          Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 14:09 +1100
          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-22 23:57 -0500
            Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-23 16:09 +1100
            Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 04:45 -0800
              Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 10:10 -0500
                Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 08:00 -0800
                  Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-26 20:37 -0500
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 12:44 +1100
                    Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-26 21:20 -0500
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 13:27 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-26 23:29 -0500
                        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 15:40 +1100
                        Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-27 11:15 -0500
                          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 11:42 -0500
                            Re: cascading python executions only if return code is 0 Rustom Mody <rustompmody@gmail.com> - 2013-12-27 22:39 +0530
                            Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-28 08:24 +1100
                            Re: cascading python executions only if return code is 0 pecore@pascolo.net - 2013-12-28 00:59 +0100
                              Re: cascading python executions only if return code is 0 Gene Heskett <gheskett@wdtv.com> - 2013-12-27 19:12 -0500
                    Re: cascading python executions only if return code is 0 Tim Chase <python.list@tim.thechases.com> - 2013-12-26 20:50 -0600
                    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-27 15:39 +1100
                      Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 15:45 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 00:05 -0500
                        Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-27 16:15 +1100
                          Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-27 00:41 -0500
                    Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-27 18:00 +0000
                    Re: cascading python executions only if return code is 0 Grant Edwards <invalid@invalid.invalid> - 2013-12-30 17:36 +0000
                Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 04:05 +1100
                  Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 11:03 -0800
                    Re: cascading python executions only if return code is 0 Chris Angelico <rosuav@gmail.com> - 2013-12-24 06:12 +1100
                    RE: cascading python executions only if return code is 0 Nick Cash <nick.cash@npcinternational.com> - 2013-12-23 19:31 +0000
                    Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 14:41 +1100
                      Re: cascading python executions only if return code is 0 Roy Smith <roy@panix.com> - 2013-12-23 22:58 -0500
                Re: cascading python executions only if return code is 0 Peter Otten <__peter__@web.de> - 2013-12-23 18:45 +0100
            Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 13:20 +0000
          Re: cascading python executions only if return code is 0 Ethan Furman <ethan@stoneleaf.us> - 2013-12-23 04:38 -0800
          Re: cascading python executions only if return code is 0 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-23 10:12 -0500
            Re: cascading python executions only if return code is 0 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-24 04:13 +1100
          Re: cascading python executions only if return code is 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-23 15:22 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#62767

On Fri, Dec 27, 2013 at 3:29 PM, Roy Smith <roy@panix.com> wrote:
> NTP is never supposed to move the clock backwards.  If your system clock
> is fast, it's supposed to reduce the rate your clock runs until it's
> back in sync.  Well, maybe it only does that for small corrections?

The exact rules are tweakable, but yes, it slews for small corrections
and steps for larger ones.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62805

On Thu, 26 Dec 2013 23:29:30 -0500, Roy Smith <roy@panix.com> declaimed the
following:

>
>NTP is never supposed to move the clock backwards.  If your system clock 
>is fast, it's supposed to reduce the rate your clock runs until it's 
>back in sync.  Well, maybe it only does that for small corrections?

	Especially likely when one considers that M$ Windows only does a time
synch once a week.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#62810

In article <mailman.4668.1388160953.18130.python-list@python.org>,
 Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> On Thu, 26 Dec 2013 23:29:30 -0500, Roy Smith <roy@panix.com> declaimed the
> following:
> 
> >
> >NTP is never supposed to move the clock backwards.  If your system clock 
> >is fast, it's supposed to reduce the rate your clock runs until it's 
> >back in sync.  Well, maybe it only does that for small corrections?
> 
> 	Especially likely when one considers that M$ Windows only does a time
> synch once a week.

When I attempt to reason about what is possible and what is impossible 
in a program, I assume a sane universe.  Windows violates that 
assumption.  I am not responsible for what happens after that.

People complain that Python 3 has been out for 5 years and the world is 
still dragging its feet upgrading from Python 2.  NTP has been around 
for almost 30 years.

Keeping a bunch of clocks on a network in sync is a solved problem.  The 
world really needs to move on to new problems like how to deal with more 
than 2^32 devices on a network.  Or how to deal with languages where 26 
letters isn't enough.

[toc] | [prev] | [next] | [standalone]

#62811

On Fri, Dec 27, 2013 at 10:12 PM, Roy Smith wrote:
> In article <mailman.4668.1388160953.18130.python-list@python.org>,
>  Dennis Lee Bieber  wrote:
>
>> On Thu, 26 Dec 2013 23:29:30 -0500, Roy Smith <roy@panix.com> declaimed the
>> following:
>>
>> >
>> >NTP is never supposed to move the clock backwards.  If your system clock
>> >is fast, it's supposed to reduce the rate your clock runs until it's
>> >back in sync.  Well, maybe it only does that for small corrections?
>>
>>       Especially likely when one considers that M$ Windows only does a time
>> synch once a week.
>
> When I attempt to reason about what is possible and what is impossible
> in a program, I assume a sane universe.

Hmm...
Any clues for a pathway to this alternate universe?
:D

[toc] | [prev] | [next] | [standalone]

#62826

On Sat, Dec 28, 2013 at 3:42 AM, Roy Smith <roy@panix.com> wrote:
> Keeping a bunch of clocks on a network in sync is a solved problem.  The
> world really needs to move on to new problems like how to deal with more
> than 2^32 devices on a network.  Or how to deal with languages where 26
> letters isn't enough.

*clap* Very tidy, finding two examples that were both solved in 1996. I like.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62828

Roy Smith <roy@panix.com> writes:

> Or how to deal with languages where 26 letters isn't enough.

English! that is, imvho
English is in sore need
of some more letters[*]
and of diacriticals too
                      g
[*] unable to quantify!

[toc] | [prev] | [next] | [standalone]

#62837

On Friday 27 December 2013 19:07:08 pecore@pascolo.net did opine:

> Roy Smith <roy@panix.com> writes:
> > Or how to deal with languages where 26 letters isn't enough.
> 
> English! that is, imvho
> English is in sore need
> of some more letters[*]
> and of diacriticals too
>                       g
> [*] unable to quantify!

You know, this gentleman is indeed correct.  But since that is all I have 
ever been speaking/reading/writing for almost 80 years, please have the 
courtesy of waiting to extend the character set and grammatical rules until 
after I've passed.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

If one studies too zealously, one easily loses his pants.
		-- A. Einstein.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

[toc] | [prev] | [next] | [standalone]

#62764

On 2013-12-27 12:44, Chris Angelico wrote:
> On Fri, Dec 27, 2013 at 12:37 PM, Roy Smith <roy@panix.com> wrote:
> > In article <mailman.4567.1387819120.18130.python-list@python.org>,
> >  Ethan Furman <ethan@stoneleaf.us> wrote:
> >  
> >> Mostly I don't want newbies thinking "Hey!  I can use assertions
> >> for all my confidence testing!"  
> >
> > How about this one, that I wrote yesterday;
> >
> >         assert second >= self.current_second, "time went
> > backwards"
> >
> > I think that's pretty high up on the "can never happen" list.  
> 
> assert second >= self.current_second, "user changed the clock"

There appears to be a Whovian at the wheel...

>>> from getpass import getuser
>>> getuser()
'doctor4'


Or perhaps a Star Trek fan:

>>> from startrek.movie import episode
>>> episode()
4


It's-clearly-past-my-bedtime-or-is-it-before'ly yers,

-tkc

[toc] | [prev] | [next] | [standalone]

#62766

Roy Smith wrote:

> In article <mailman.4567.1387819120.18130.python-list@python.org>,
>  Ethan Furman <ethan@stoneleaf.us> wrote:
> 
>> Mostly I don't want newbies thinking "Hey!  I can use assertions for all
>> my confidence testing!"
> 
> How about this one, that I wrote yesterday;
> 
>         assert second >= self.current_second, "time went backwards"
> 
> I think that's pretty high up on the "can never happen" list.

Time goes backwards by one hour[1] at least once a year across most of the
world. 

http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time-wisdom



[1] Unless it's less than an hour. Or more than one hour.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#62769

On Fri, Dec 27, 2013 at 3:39 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Time goes backwards by one hour[1] at least once a year across most of the
> world.
>
> http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time-wisdom
>
> [1] Unless it's less than an hour. Or more than one hour.

Kinda. That should be accompanied by a change in UTC offset,
indicating that time hasn't gone backwards, just the clock. Anything
that queries the clock in UTC shouldn't see it go backward. But if
there's a time server that's misconfigured, and it actually jumps time
backward, then yes, you could see NTP change the time back by an hour
once a year. It's wrong, but it certainly can happen.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62772

In article <52bd049d$0$29992$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Roy Smith wrote:
> 
> > In article <mailman.4567.1387819120.18130.python-list@python.org>,
> >  Ethan Furman <ethan@stoneleaf.us> wrote:
> > 
> >> Mostly I don't want newbies thinking "Hey!  I can use assertions for all
> >> my confidence testing!"
> > 
> > How about this one, that I wrote yesterday;
> > 
> >         assert second >= self.current_second, "time went backwards"
> > 
> > I think that's pretty high up on the "can never happen" list.
> 
> Time goes backwards by one hour[1] at least once a year across most of the
> world. 

Only if you're stupid enough to run your systems in local time.

> http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-a
> bout-time-wisdom

Most of those deal with things like daylight saving time and time zones 
and calendars, which are all far more complicated (and chaotic) than 
just keeping track of UTC timestamps.

There's lists like that for names and genders too.  As in, what do you 
mean there are people who don't have exactly two names and one gender?

[toc] | [prev] | [next] | [standalone]

#62776

On Fri, Dec 27, 2013 at 4:05 PM, Roy Smith <roy@panix.com> wrote:
> There's lists like that for names and genders too.  As in, what do you
> mean there are people who don't have exactly two names and one gender?

And addresses, too. The only way to reliably query the user for an
address is with a single field in which s/he may type anything at
all... and that freedom includes the possibility of making a right
hash of it and having delivery fail.

ChrisA

[toc] | [prev] | [next] | [standalone]

#62779

In article <mailman.4653.1388121800.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Dec 27, 2013 at 4:05 PM, Roy Smith <roy@panix.com> wrote:
> > There's lists like that for names and genders too.  As in, what do you
> > mean there are people who don't have exactly two names and one gender?
> 
> And addresses, too. The only way to reliably query the user for an
> address is with a single field in which s/he may type anything at
> all... and that freedom includes the possibility of making a right
> hash of it and having delivery fail.
> 
> ChrisA

You're assuming people *have* addresses.

A bunch of years ago (I'm probably dating myself), there was a legal 
ruling in New York that having an address was not a requirement to 
register to vote.  The case in question had to do with a homeless person 
who was refused registration because he didn't have an address.

[toc] | [prev] | [next] | [standalone]

#62814

On 27/12/2013 01:44, Chris Angelico wrote:
> On Fri, Dec 27, 2013 at 12:37 PM, Roy Smith <roy@panix.com> wrote:
>> In article <mailman.4567.1387819120.18130.python-list@python.org>,
>>   Ethan Furman <ethan@stoneleaf.us> wrote:
>>
>>> Mostly I don't want newbies thinking "Hey!  I can use assertions for all my
>>> confidence testing!"
>>
>> How about this one, that I wrote yesterday;
>>
>>          assert second >= self.current_second, "time went backwards"
>>
>> I think that's pretty high up on the "can never happen" list.
>
> assert second >= self.current_second, "user changed the clock"
>
> ChrisA
>

assert "shoot admin who gave user too much privilege" ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#62891

On 2013-12-27, Roy Smith <roy@panix.com> wrote:
> In article <mailman.4567.1387819120.18130.python-list@python.org>,
>  Ethan Furman <ethan@stoneleaf.us> wrote:
>
>> Mostly I don't want newbies thinking "Hey!  I can use assertions for all my 
>> confidence testing!"
>
> How about this one, that I wrote yesterday;
>
>         assert second >= self.current_second, "time went backwards"
>
> I think that's pretty high up on the "can never happen" list.

It's not that high (depending on where you're getting "second" from).
If the "second" is from the time of day, and the NTP daemon (or the
system admin) decides the clock needs a stepwise adjustment, the time
of day can go backwards.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#62642

Roy Smith wrote:

> Sigh.  Sometimes I'm not sure which is worse.  The anti-assertion
> zealotry on this list, or the anti-regex zealotry.

I'm not anti-assertions. I love assertions. I wouldn't be surprised if I use
assert more than you do. What I dislike is people misusing assertions.

> And, yes, I know that assertions get turned off with -O (frankly, I
> think that's a design flaw).  We don't run with -O.

Until such time as somebody decides they can speed up your code by 5% by
running with optimizations turned on.

Unfortunately, it's not always clear when an assert is appropriate and when
it isn't. Fundamentally, if an assertion can never fail[1], then there's no
point testing for it:

x = []
assert x == [] and len(x) == 0

So there's always tension between "why am I testing something that can't
fail?" and "but what if it does?", and different people are going to draw
the line in different places. So even if you and I draw the line in
different places, I can acknowledge that you seem to be using asserts the
same way I would, as executable comments and for testing program
invariants, and I'm sorry that my rant was aimed in your direction
unnecessarily.





[1] Short of hardware failure or serious bugs in the compiler, but in both
those cases you can't trust the assertions to trigger correctly either.

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#62647

On Monday, December 23, 2013 12:05:22 PM UTC-5, Steven D'Aprano wrote:
> Roy Smith wrote:

> > And, yes, I know that assertions get turned off with -O (frankly, I
> > think that's a design flaw).  We don't run with -O.
> 
> 
> Until such time as somebody decides they can speed up your code by 5% by
> running with optimizations turned on.

Well, there's lots of changes people could make that would break things.  Many of them are in the name of efficiency. [1]  But, let's say they did that.  We would fall off the end of the function, return None, and the caller would end up doing:

with None:
    whatever

leaving somebody to puzzle over why the logs contained a stack dump ending in:

AttributeError: __exit__

So, here's the deeper question.  Is your issue strictly that -O elides assert statements? [2]  That's a purely mechanical issue that could be solved by using the rather more verbose:

if not condition:
    raise AssertionError("....")

Would you feel differently then?

> So there's always tension between "why am I testing something that can't
> fail?" and "but what if it does?"

Trust, but verify.  Especially when the thing you're verifying is your understanding of how your own code works :-)

[1] and most of those are premature optimizations.  To a first order approximation, for us, application speed is all about database performance, and not at all about Python code execution speed.  That's a pretty good second order approximation as well.

[2] In which case, we would just add some middleware which did:

assert "-O" not in sys.argv

[toc] | [prev] | [next] | [standalone]

#62649

On Tue, Dec 24, 2013 at 6:03 AM, Roy Smith <roy@panix.com> wrote:
> [2] In which case, we would just add some middleware which did:
>
> assert "-O" not in sys.argv

Aside from the fact that this wouldn't work, it won't work :) By the
time you see argv, the -O option has been eaten. But why stop at that?

def assertions_working():
    try:
        assert False
    except AssertionError:
        return True
    return False

assert assertions_working()  # refuse to run in -O mode

Can't imagine why that wouldn't work......

ChrisA

[toc] | [prev] | [next] | [standalone]

#62653

> assert assertions_working()  # refuse to run in -O mode
> 
> Can't imagine why that wouldn't work......

Why overthink this? 

assert not sys.flags.optimize

is clearly the one, and only one, obvious way to do it. 

Of course, it works about as well as the rest of these solutions. Which is to say, not at all.

-Nick Cash

[toc] | [prev] | [next] | [standalone]

#62665

Roy Smith wrote:

> So, here's the deeper question.  Is your issue strictly that -O elides
> assert statements?  That's a purely mechanical issue that could be
> solved by using the rather more verbose:
> 
> if not condition:
>     raise AssertionError("....")
> 
> Would you feel differently then?


Not quite. As I said in my initial rant, there's also the issue of using an
appropriate exception. Naming is important for comprehending what the code
does. Just as it's bad to do:

my_list = 42
my_str = [my_list * 2]


so it's bad to have badly chosen exceptions:

def handle_string(s):
    if not isinstance(s, str):
        raise ImportError("not a string")
    ...


Substitute AssertionError for ImportError:

def handle_string(s):
    if not isinstance(s, str):
        raise AssertionError("not a string")
    ...


and it's still wrong because the exception is misleading and/or confusing to
whoever has to deal with the code.

I've been known to use asserts inside private functions and explicit tests
inside public ones:

def func(x):
    if x <= 0:
        raise ValueError("x must be positive")
    return _func(x + 1)

def _func(x):
    assert x > 1
    return sqrt(1/(x-1))


If I think that the test is checking an internal invariant, assert is okay,
if not, it isn't. In this case, the fact that the actual calculation of
func(x) is factored out into a private function _func is purely an internal
implementation issue. I might refactor the code and move _func inline:

def func(x):
    if x <= 0:
        raise ValueError("x must be positive")
    x += 1
    assert x > 1
    return sqrt(1/(x-1))


in which case the assertion is obviously checking an internal invariant and
therefore acceptable. So it's still checking an internal invariant even
when the code is moved into a purely internal function.

The other rule I use is that if an assert might ever be triggered in the
normal run of the program, it shouldn't be an assert. In principle, we
should run Python code with -O in production.

(It would have been better if Python optimized code by default, and had a -D
switch to turn debugging on, including asserts. I believe that's what
languages like Eiffel do.)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web