Loop until condition is true

[Remi Villatel]

Hi there,

There is always a "nice" way to do things in Python but this time I can't
find one.

What I'm trying to achieve is a conditionnal loop of which the condition
test would be done at the end so the loop is executed at least once. It's
some way the opposite of "while".

So far, all I got is:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.

Is there a better recipe?

--
==================
Remi Villatel
maxilys_@_tele2.fr
==================

[Donn Cave]

Quoth Remi Villatel <maxilys@SPAMCOP_tele2.fr>:

| What I'm trying to achieve is a conditionnal loop of which the condition
| test would be done at the end so the loop is executed at least once. It's
| some way the opposite of "while".
|
| So far, all I got is:
|
| while True:
| some(code)
| if final_condition is True:
| break
| #
| #
|
| What I don't find so "nice" is to have to build an infinite loop only to
| break it.
|
| Is there a better recipe?

It depends, but that isn't too bad. The alternative would be flag
variable, like "looping = 1; while looping: ..."

The construct you're looking for is "until" in C, and there have been
plenty of proposals to add this or other improvements to Python's
repertoire. As far as I know, it hasn't happened because it isn't
really needed. If you look at C code, at least in my experience the
"until" loop is quite rarely used. (I don't see it once in the source
to Python 2.4, for example.) Meanwhile, the "while True" (or "while 1")
idiom is very familiar to Python programmers (just as the Python source
has dozens of "for (;;)"), so it's preferred for legibility. It's nice,
don't worry.

Donn Cave, do**@drizzle.com

[Peter Otten]

Donn Cave wrote:

If*you*look*at*C*code,*at*least*in*my*experience*t he
"until" loop is quite rarely used.**(I*don't*see*it*once*in*the*source
to Python 2.4, for example.)

Long time no C?

'until' in C is actually

do
statement
while (expression);

I found 136 occurrences of "do {" versus 754 of "while (" and 1224 of "for
(" in the Python 2.4 source, so using these rough estimates do-while still
qualifies as "rarely used".

Peter

[Grant Edwards]

On 2005-06-18, Peter Otten <__*******@web.de> wrote:

If*you*look*at*C*code,*at*least*in*my*experience*t he
"until" loop is quite rarely used.**(I*don't*see*it*once*in*the*source
to Python 2.4, for example.)

Long time no C?

'until' in C is actually

do
statement
while (expression);

I found 136 occurrences of "do {" versus 754 of "while (" and 1224 of "for
(" in the Python 2.4 source, so using these rough estimates do-while still
qualifies as "rarely used".

AFAICT, the main use for do/while in C is when you want to
define a block of code with local variables as a macro:

#define DoSomething(foo) \
do \
{ \
int i; \
/* do something with foo and i */ \
} while (0)

--
Grant Edwards grante Yow! I HIJACKED a 747 to
at get here!! I hope those
visi.com fabulous CONEHEADS are
at HOME!!

[Tim Williams]

----- Original Message -----
From: "Remi Villatel" <maxilys@SPAMCOP_tele2.fr>

There is always a "nice" way to do things in Python but this time I can't
find one. So far, all I got is:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.

If your final_condition is already defined outside the "while" then how
about

while not final_condition:
some(code)

Simplistically, this equates to

x = 0
while not x == 5: .... x += 1
.... print x

5

:)

[Donn Cave]

Quoth Peter Otten <__*******@web.de>:
....
| 'until' in C is actually
|
| do
| statement
| while (expression);

Oops. Well, QED - I sure don't need it often.

Donn Cave, do**@drizzle.com

[Andrea Griffini]

On Sat, 18 Jun 2005 13:35:16 -0000, Grant Edwards <gr****@visi.com>
wrote:

AFAICT, the main use for do/while in C is when you want to
define a block of code with local variables as a macro:

When my job was squeezing most out of the CPU (videogame
industry) I remember that the asm code generated by

while (sz-- > 0)
{
/* do some stuff */
}

was indeed worse than

do
{
/* do some stuff */
} while (--sz);

because of the initial "empty-loop" test (conditional jumps
were bad, and forward conditional jumps were worse).
So where at least one iteration was guaranteed the do-while
loop was a better choice.

Also I've been told there were compilers that if using
for or while loops the generated code was

<initialize>
L1:
<evaluate condition>
je L2
<body>
jmp L1
L2:

Instead the do-while loop would have been

L1:
<body>
<evaluate condition>
jne L1

I.e. the code was better *for each iteration* (one conditional
jump instead of one conditional jump and one inconditional jump).

I think compiler got better since then, even if I don't think
they already so smart to be able to infer the "one interation
guaranteed" property to avoid the initial test that often.

Andrea

[Michael J. Fromberger]

In article <nh********************************@4ax.com>,
Andrea Griffini <ag****@tin.it> wrote:

On Sat, 18 Jun 2005 13:35:16 -0000, Grant Edwards <gr****@visi.com>
wrote:

AFAICT, the main use for do/while in C is when you want to
define a block of code with local variables as a macro:

When my job was squeezing most out of the CPU (videogame
industry) I remember that the asm code generated by

while (sz-- > 0)
{
/* do some stuff */
}

was indeed worse than

do
{
/* do some stuff */
} while (--sz);

because of the initial "empty-loop" test (conditional jumps
were bad, and forward conditional jumps were worse).
So where at least one iteration was guaranteed the do-while
loop was a better choice.

Hmm. I don't know what compiler you were using, but in my experience
it's fairly typical to compile while(<test> ...) { <body> ... } as

j test
body: <body>
...
test: <test>
...
je body ;; or whatever your condition is

To turn this into a do { <body> ... } while(<test> ...), you need only
remove the initial "j test" instruction. Even if forward conditional
jumps are bad for your particular architecture, this method avoids the
problem neatly.

Personally, I'd be pretty suspicious of the quality of a compiler that
produced radically different code for these two constructs without some
damned good reason.

-M

--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA

[Magnus Lycka]

Remi Villatel wrote:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.
This is a common Python idiom. I think you will get used to it.

Is there a better recipe?

final_condition = False
while not final_condition:
some(code)

[Benji York]

Cyril BAZIN wrote:

Another question could be: why is there not a statement "whileTrue" or
"loop"?
I don't think the saving of a single space to transform "while True:"
into "WhileTrue:" is really worth it. The same goes for "loop", the
added complexity to the language (as little as it is) isn't rewarded by
a large enough improvement to make it worth it.
It could be an economy of one unuseful test by loop.

If by "economy" you mean "optimization", then I would suggest that the
difference would be unnoticeable.
--
Benji York

[Charles Krug]

On Tue, 21 Jun 2005 12:05:25 +0200, Magnus Lycka <ly***@carmen.se> wrote:

Remi Villatel wrote:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.

This is a common Python idiom. I think you will get used to it.

Is there a better recipe?

final_condition = False
while not final_condition:
some(code)

To the OP, don't get hung up on the syntax we use to implement a loop.

I took my first programming class long enough ago that we had to do
things like this (roughly translating the FORTRAN IV I remember into
p-code)

To do:

while TrueCondition
(loop body)

we'd have to write:

TopOfLoop:
if not TrueConditional goto loopEnd
(loop body)
goto TopOfLoop

loopEnd:

We were even required to write our source twice:

The first pass was "structured" and had to be proven correct.

The second pass was translated into something our compiler supported.

We still called it a "while loop" even though the syntax was icky.

When C came out with its built in looping, it was an unbelievable
luxury.

[Magnus Lycka]

Benji York wrote:

If by "economy" you mean "optimization", then I would suggest that the
difference would be unnoticeable.

If there is a measurable performance gain in skipping the runtime
test in "while True", then this is a compiler issue, not a language
issue. I don't know anything about the Python compiler internals,
but it doesn't seem very hard to identify simple literals following
while and if, and to skip the runtime test. (Perhaps it's done
already?)

I hope the time is over when language designers build ugly quirks
into programming language syntaxes to make life a little easier for
the compilers.

[Fredrik Lundh]

Remi Villatel wrote:

There is always a "nice" way to do things in Python but this time I can't
find one.

What I'm trying to achieve is a conditionnal loop of which the condition
test would be done at the end so the loop is executed at least once. It's
some way the opposite of "while".

So far, all I got is:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.

the correct way to write that if-statement is:

if final_condition:
break

and yes, the "infinite" while loop is a standard Python pattern. get
used to it.

</F>

[Konstantin Veretennicov]

On 6/21/05, Magnus Lycka <ly***@carmen.se> wrote:

I don't know anything about the Python compiler internals,
but it doesn't seem very hard to identify simple literals following
while and if, and to skip the runtime test. (Perhaps it's done
already?)

True doesn't seem to be a literal, it is looked up by name and can be
rebound to, say, 0 anytime:

import dis
o = compile('while True: pass', '<string>', 'exec')
dis.dis(o) 1 0 SETUP_LOOP 12 (to 15)

3 LOAD_NAME 0 (True) 6 JUMP_IF_FALSE 4 (to 13)
9 POP_TOP
10 JUMP_ABSOLUTE 3
...

OTOH,
p = compile('while 1: pass', '<string>', 'exec')
dis.dis(p)

1 0 SETUP_LOOP 5 (to 8) 3 JUMP_ABSOLUTE 3

...

- kv

[Magnus Lycka]

Konstantin Veretennicov wrote:

On 6/21/05, Magnus Lycka <ly***@carmen.se> wrote:

I don't know anything about the Python compiler internals,
but it doesn't seem very hard to identify simple literals following
while and if, and to skip the runtime test. (Perhaps it's done
already?)

True doesn't seem to be a literal, it is looked up by name and can be
rebound to, say, 0 anytime:

Right. Silly me. Maybe in some future Python version, True and False
will be constants, like None is since Python 2.4.

[Stelios Xanthakis]

Magnus Lycka wrote:

Konstantin Veretennicov wrote:

On 6/21/05, Magnus Lycka <ly***@carmen.se> wrote:

I don't know anything about the Python compiler internals,
but it doesn't seem very hard to identify simple literals following
while and if, and to skip the runtime test. (Perhaps it's done
already?)

True doesn't seem to be a literal, it is looked up by name and can be
rebound to, say, 0 anytime:

Right. Silly me. Maybe in some future Python version, True and False
will be constants, like None is since Python 2.4.

Actually, there is support in marshal to write True and False objects so
I don't understand why this isn't in 2.4

Anyway, if you can't wait for 2.5 either use 'while 1:', or pyc[1]

Stelios

[1] http://students.ceid.upatras.gr/~sxanth/pyc/

[Remi Villatel]

Fredrik Lundh wrote:

while True:
some(code)
if final_condition is True:
break
#
#

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.
Erm... You totally missed the point. I wrote it this way because, first,
it's perfectly valid Python code and, second and most important, it's also a
valid english sentence.

[CENSORED] I keep for myself how stupid I found your post.
the correct way to write that if-statement is:
Don't try to teach your grandfather how to suck eggs. There is no "correct
way" to code and "superfluous" isn't a synonym of "incorrect".
and yes, the "infinite" while loop is a standard Python pattern. get
used to it.

Grandfathers and eggs. Now, excuse me but I have a group of savage AI
written in bad style Python to tame.

--
==================
Remi Villatel
maxilys_@_tele2.fr
==================

[Steven D'Aprano]

On Wed, 22 Jun 2005 02:01:14 +0200, Remi Villatel wrote:

Fredrik Lundh wrote:

while True:
some(code)
if final_condition is True:
break
#
#

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.
Erm... You totally missed the point. I wrote it this way because, first,
it's perfectly valid Python code and, second and most important, it's also a
valid english sentence.

Why is it more important for Python code to be a valid English sentence
than for it to be valid Python code?

Does that mean that instead of writing:

squares = [x**2 for x in range(10)]

you instead write the valid English sentence:

the list of squares is given by the set of x squared for x between 0 and 9
inclusive

?

The point being, I would have thought that most programmers would have put
"being a valid English sentence" right down at the bottom of their list of
optional conditions, and not as the "most important" requirement ahead of
even being valid code.

I also question your understanding of valid English. I don't know about
you, but I usually say "if the apple is on the bench..." and hardly ever
"if the apple is on the bench is true...".

[CENSORED] I keep for myself how stupid I found your post.
Whatever.

the correct way to write that if-statement is:

Don't try to teach your grandfather how to suck eggs.

It must be nice to have learnt everything that there is to learn
about Python. I hope I get there someday.
There is no "correct
way" to code and "superfluous" isn't a synonym of "incorrect".

"if final_condition" will always work.

"if final_condition is True" will break if final_condition is not a bool.
Depending on where final_condition gets its result from, that may or may
not be a high risk. It also relies on an implementation detail, that True
and False are singletons (doubletons?), and will break if that changes.
And finally, since True is just an object, and not a constant like None,
it will break if True gets set to some other value.

In other words, it is not only superfluous but also fragile.
--
Steven.

[Shane Hathaway]

Remi Villatel wrote:

Hi there,

There is always a "nice" way to do things in Python but this time I can't
find one.

What I'm trying to achieve is a conditionnal loop of which the condition
test would be done at the end so the loop is executed at least once. It's
some way the opposite of "while".

So far, all I got is:

while True:
some(code)
if final_condition is True:
break
#
#

What I don't find so "nice" is to have to build an infinite loop only to
break it.

FWIW, my own experience is that the "while True" idiom is actually safer
and better than alternatives like do/while. I used to write do/while
loops all the time, but I wound up with more than my fair share of
unintentionally infinite loops. I put too much trust in the syntax: I
expected that since I was using the cleaner construct, I didn't have to
worry about infinite loops.

Now, I think of "while True" not as an infinite loop, but rather as a
sign reminding me to be wary of looping infinitely in a particular spot.
I feel like this has resulted in a lot fewer infinite loops in my own
code. Now I believe that any loop that can't be represented well with
"for" or a conditional "while" has enough inherent complexity to justify
a warning sign, and "while True" has bright yellow flashing lights all
over it. Thus I'm quite in favor of the status quo.

Shane

[Fredrik Lundh]

Remi Villatel wrote:

while True:
some(code)
if final_condition is True:
break
#
#

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.

Erm... You totally missed the point. I wrote it this way because, first,
it's perfectly valid Python code and, second and most important, it's also a
valid english sentence.

I suggest looking up "is" in the Python manual instead of looking it
up in a dictionary. (hint: it doesn't do what you think it does, and
code using your "perfectly valid" pattern doesn't always work.)
[CENSORED] I keep for myself how stupid I found your post.

so let's see if everyone who understands how embarrassingly stupid
your post is will keep that to themselves...

</F>

[Ville Vainio]

>>>>> "Stelios" == Stelios Xanthakis <sx****@ceid.upatras.gr> writes:

Stelios> Anyway, if you can't wait for 2.5 either use 'while 1:',
Stelios> or pyc[1]

.... and I can't see why people don't want to use 'while 1:' in the
first place, given that everyone can identify the idiom
immediately. It's 4 keystrokes less.

--
Ville Vainio http://tinyurl.com/2prnb

[Steven D'Aprano]

On Wed, 22 Jun 2005 09:54:44 +0200, Fredrik Lundh wrote:

[CENSORED] I keep for myself how stupid I found your post.

so let's see if everyone who understands how embarrassingly stupid
your post is will keep that to themselves...

Damn, did I fail some test?

<wink>

--
Steven.

[Greg Lindstrom]

A bit off topic, but what does the expression "Don't try to teach your
grandfather how to suck eggs." mean? I've never heard it before and am
curious to the story behind it.

Thanks,
--greg

[Tim Williams]

----- Original Message -----
From: "Greg Lindstrom" <tu********@gmail.com>

A bit off topic, but what does the expression "Don't try to teach your
grandfather how to suck eggs." mean? I've never heard it before and am
curious to the story behind it.

A relatively well know phrase, however as quoted it is incorrect, it
should have referred to "grandmother"

http://www.phrases.org.uk/bulletin_b...ssages/50.html
http://www.worldwidewords.org/qa/qa-tea1.htm

:)

[Magnus Lycka]

Remi Villatel wrote:

Erm... You totally missed the point. I wrote it this way because, first,
it's perfectly valid Python code and, second and most important, it's
also a valid english sentence.

Remi, I think you have failed to understand what Fredrik was
telling you. I can understand that, because he didn't actually
explain the problem. He probably thought it was obvious, but
it seems it wasn't.

"if a is b:" is equivalent to "if id(a) == id(b)". It doesn't
test whether two values are the equal, it tests whether a and b
are the same object. None is a singleton object in Python, but
True is not. (At least not in the Python versions I use.)

That means that you are relying on Python to use a performance
optimization (interning of some common values, in this case
the integer 1, which is what True is in practice).

In some cases, "==" and "is" happens to give the same result.

a = 1
b = 1
a == b 1 a is b 1

But often not.
c = 123456789
d = 123456789
c == d 1 c is d 0

Or, for an example of the opposite:
class Smaller: .... def __cmp__(self, other):
.... return -1
.... s = Smaller()
b = a
a < b 1 b < a 1 a == b 0 a is b

1

In other words, a test like "if x is None:" makes sense,
since None is a singleton, but "if x is True:" certainly
seems like buggy code that just happens to work. You could
write "if x == True:" without risking a failure in some
Python implementation that doesn't intern True (i.e. 1)
if you are certain that x is 0 or 1, but it's completely
redundant. Why stop there? Why not write
"if x == True == True:" or "if x == True == True == True:"?
These are all logically equivalent. You could also write
"if x and True:", or "if x or not True" :)

I understand what your intentions are: You feel that your
code is easier to understand written the way you did it, but
it stops feeling like that once you have gotten fully into
your head that the expressions (a) and (a == True) are
logically equivalent if a is either True or False.

If you manage to get away from this "x == True" mind-set
you are likely to write better Python code.

First of all, a lot of Python values except 1 (a.k.a. True)
are logically true in a Python expression. It's considered
good form to exploit that. E.g.

if y: z = x / y
if text: print text
if l: cols = len(l[0])

In these cases, adding a "==True", would break the code, and
adding more "correct" comparisions would just clutter the code,
which hides the intent and raises the risk for bugs, and make
it more difficult to keep the code as flexible as Python code
can be. E.g. if you change the last statement to
"if l != []: cols = len(l[0])", you'll get in trouble if it
turns out that l = (). The uncluttered code will still work.

Secondly, if you ever write logical expressions that are more
complex, you will make them much more difficult to read unless
you drop that "== True" baggage.

I'm convinced that it's easier to understand

if past_six or past_three and saturday or sunday:

than to understand

if (past_six==True or
past_three==True and saturday==True or
sunday==True):

I'm also pretty sure it's easier to write the first without
making any mistake.

[Michael Hoffman]

Remi Villatel wrote:

Fredrik Lundh wrote:

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.
I wrote it this way because, first, it's perfectly valid Python code and,
second and most important, it's also a valid english sentence.

As others have pointed out, it's not perfectly valid code. In fact it is
frequently incorrect.
[CENSORED] I keep for myself how stupid I found your post...
Don't try to teach your grandfather how to suck eggs.

You apparently don't know how to do it without getting egg on your face.
--
Michael Hoffman

[Jeff Epler]

def until(pred):
yield None
while True:
if pred(): break
yield None

def example():
i = 0
for _ in until(lambda: x==0):
x = 10 - i
i += 1
print x, i

example()

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCuZa4Jd01MZaTXX0RAobdAJ93y6PxHS7oinElXZiBSX QMA6VWoQCfaV/C
C7D/7lDsUiHBWmRZ56Yhx3g=
=q/5k
-----END PGP SIGNATURE-----

[Scott David Daniels]

Magnus Lycka wrote:

In some cases, "==" and "is" happens to give the same result.

>>> a = 1
>>> b = 1
>>> a == b 1 >>> a is b 1

But often not.
>>> c = 123456789
>>> d = 123456789
>>> c == d 1 >>> c is d 0
.... First of all, a lot of Python values except 1 (a.k.a. True)
are logically true in a Python expression....

Actually, True and 1 are interesting examples.

a, b = 1, True
a == b True
a is b

False
I suspect you simply forgot this fact.

--Scott David Daniels
Sc***********@Acm.Org

[Michael Hoffman]

Stelios Xanthakis wrote:

Magnus Lycka wrote:

Right. Silly me. Maybe in some future Python version, True and False
will be constants, like None is since Python 2.4.

Actually, there is support in marshal to write True and False objects so
I don't understand why this isn't in 2.4

Because it would break existing code.
--
Michael Hoffman

[Antoon Pardon]

Op 2005-06-22, Michael Hoffman schreef <ca*******@mh391.invalid>:

Remi Villatel wrote:

Fredrik Lundh wrote:

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.

I wrote it this way because, first, it's perfectly valid Python code and,
second and most important, it's also a valid english sentence.

As others have pointed out, it's not perfectly valid code. In fact it is
frequently incorrect.

That the same code would be incorrect in other circumstances doesn't
make it invalid as it was used in a specific situation.

I have written code my self with an "if var is True" statement and
that is exactly what I wanted. Replacing it with "if var" would
have broken the the program.

--
Antoon Pardon

[Stelios Xanthakis]

Michael Hoffman wrote:

Stelios Xanthakis wrote:

Magnus Lycka wrote:

>

Right. Silly me. Maybe in some future Python version, True and False
will be constants, like None is since Python 2.4.

Actually, there is support in marshal to write True and False objects so
I don't understand why this isn't in 2.4

Because it would break existing code.

Yes. Code that has variables named 'True' and 'False'.
Stelios

[Mike Meyer]

Stelios Xanthakis <sx****@ceid.upatras.gr> writes:

Michael Hoffman wrote:

Stelios Xanthakis wrote:

Magnus Lycka wrote:
>

Right. Silly me. Maybe in some future Python version, True and False
will be constants, like None is since Python 2.4.
Actually, there is support in marshal to write True and False objects so
I don't understand why this isn't in 2.4

Because it would break existing code.

Yes. Code that has variables named 'True' and 'False'.

Making None a constant broke existing code (and I just saw old code
that assigned to None). Are True and False that much more common as
variable names than None?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Benji York]

Mike Meyer wrote:

Making None a constant broke existing code (and I just saw old code
that assigned to None). Are True and False that much more common as
variable names than None?

I would think so. I know that my pre-booleans-in-Python code routinely
did something like "from booleans import True, False". Of course the
fix is easy, but it still must be applied before the code will run.
--
Benji York

[Michael Hoffman]

Mike Meyer wrote:

Making None a constant broke existing code (and I just saw old code
that assigned to None). Are True and False that much more common as
variable names than None?

Yes. In fact, I count at least 4 different modules in the Python 2.4
standard library that assign to True or False, mainly as a
compatibility measure for the days before they were built-ins. If you
try assigning None, CPython will refuse to compile the module, even if
the code where None is assigned is unreachable.

If there was ever a good reason to assign to None, I don't know it.
--
Michael Hoffman

[Michael Hoffman]

Antoon Pardon wrote:

Op 2005-06-22, Michael Hoffman schreef <ca*******@mh391.invalid>:

Remi Villatel wrote:

Fredrik Lundh wrote:

checking if a logical expression is true by comparing it to True is bad
style, and comparing values using "is" is also bad style.

I wrote it this way because, first, it's perfectly valid Python code and,
second and most important, it's also a valid english sentence.

As others have pointed out, it's not perfectly valid code. In fact it is
frequently incorrect.

That the same code would be incorrect in other circumstances doesn't
make it invalid as it was used in a specific situation.

I have written code my self with an "if var is True" statement and
that is exactly what I wanted. Replacing it with "if var" would
have broken the the program.

That point was not lost on me (which is why I said it was frequently
incorrect). I think it was lost on the OP though.
--
Michael Hoffman

[Roy Smith]

Michael Hoffman <ca*******@mh391.invalid> wrote:

I count at least 4 different modules in the Python 2.4 standard
library that assign to True or False, mainly as a compatibility
measure for the days before they were built-ins.

Hopefully, none of them as creative as
http://thedailywtf.com/forums/36067/ShowPost.aspx

[Mike Meyer]

Michael Hoffman <ca*******@mh391.invalid> writes:

Mike Meyer wrote:

Making None a constant broke existing code (and I just saw old code
that assigned to None). Are True and False that much more common as
variable names than None?

Yes. In fact, I count at least 4 different modules in the Python 2.4
standard library that assign to True or False, mainly as a
compatibility measure for the days before they were built-ins. If you
try assigning None, CPython will refuse to compile the module, even if
the code where None is assigned is unreachable.

If there was ever a good reason to assign to None, I don't know it.

For the record, the code I just saw did something like this:

(var1, var2, None, None) = make_tuple(args)

Pretty clearly, they were just throwing away some unused values. Who
knows what it did to None...

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.