Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > while 1 vs while True

Reply
Thread Tools

while 1 vs while True

 
 
Timothy Fitz
Guest
Posts: n/a
 
      12-13-2004
[ http://www.python.org/moin/PythonSpeed ]
"Starting with Py2.3, the interpreter optimizes 'while 1' to just a
single jump. In contrast "while True" takes several more steps. While
the latter is preferred for clarity, time-critical code should use the
first form."

Out of pure curiousity,
Why wasn't 'While True' optimized also?
 
Reply With Quote
 
 
 
 
Dan Bishop
Guest
Posts: n/a
 
      12-13-2004
Timothy Fitz wrote:
> [ http://www.python.org/moin/PythonSpeed ]
> "Starting with Py2.3, the interpreter optimizes 'while 1' to just a
> single jump. In contrast "while True" takes several more steps. While
> the latter is preferred for clarity, time-critical code should use

the
> first form."
>
> Out of pure curiousity,
> Why wasn't 'While True' optimized also?


Probably has something to do with "True" and "False" not being
constants.

>>> True = 0
>>> while True:

.... print 'Not an infinite loop. In fact, it never executes at all.'

 
Reply With Quote
 
 
 
 
Nick Coghlan
Guest
Posts: n/a
 
      12-13-2004
Dan Bishop wrote:
>>Out of pure curiousity,
>>Why wasn't 'While True' optimized also?

>
>
> Probably has something to do with "True" and "False" not being
> constants.


Yup. Even 'None' only just became a constant in 2.4.

I don't know if 'True' and 'False' are in line for similar treatment (there are
obvious backwards compatibility issues in doing so).

Cheers,
Nick.

--
Nick Coghlan | http://www.velocityreviews.com/forums/(E-Mail Removed) | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
 
Reply With Quote
 
Raymond Hettinger
Guest
Posts: n/a
 
      12-14-2004
> Dan Bishop wrote:
> >>Out of pure curiousity,
> >>Why wasn't 'While True' optimized also?

> >
> >
> > Probably has something to do with "True" and "False" not being
> > constants.


[Nick Coghlan]
> Yup. Even 'None' only just became a constant in 2.4.
>
> I don't know if 'True' and 'False' are in line for similar treatment (there

are
> obvious backwards compatibility issues in doing so).


It is unlike to before Py3.0. Making them constants would break the reams of
compatability code: True, False = (1==1), (1!=1).


Raymond Hettinger


 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      12-14-2004
"Raymond Hettinger" <(E-Mail Removed)> writes:
> It is unlike to before Py3.0. Making them constants would break the
> reams of compatability code: True, False = (1==1), (1!=1).


I don't see why that particular statement needs to fail. The
interpreter could permit assigning True=True or False=False without
raising an error. Then True and False wouldn't really be constants,
but they'd instead be variables whose value was always known to the
compiler, which for optimization purposes is just as good. The
compiler could alternatively do some simple dataflow analysis to make
sure the values of True and False haven't been changed in a particular
module, before doing that particular optimization.
 
Reply With Quote
 
Nick Coghlan
Guest
Posts: n/a
 
      12-14-2004
Paul Rubin wrote:
> "Raymond Hettinger" <(E-Mail Removed)> writes:
>
>>It is unlike to before Py3.0. Making them constants would break the
>>reams of compatability code: True, False = (1==1), (1!=1).

>
>
> I don't see why that particular statement needs to fail. The
> interpreter could permit assigning True=True or False=False without
> raising an error. Then True and False wouldn't really be constants,
> but they'd instead be variables whose value was always known to the
> compiler, which for optimization purposes is just as good. The
> compiler could alternatively do some simple dataflow analysis to make
> sure the values of True and False haven't been changed in a particular
> module, before doing that particular optimization.


Until this code:

..>>> import pdb
..>>> pdb.True = 0
..>>> pdb.x = "Darn writeable module dictionaries"
..>>> from pdb import True
..>>> True
0
..>>> from pdb import x
..>>> x
'Darn writeable module dictionaries'


is illegal, the compiler is really limited in what it can safely assume about
the contents of module dictionaries. There's such a thing as being *too*
flexible - and in this case, the flexibility eliminates some potential
optimisations (in this case, "I know what this is" compile time name binding).

I believe modifying a module's globals dictionary from outside the module is in
the process of being deprecated - the catch is that distinguishing it from some
legitimate accesses to a module's globals is not straightforward.

Cheers,
Nick.

--
Nick Coghlan | (E-Mail Removed) | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      12-14-2004
Nick Coghlan <(E-Mail Removed)> writes:
> Until this code:
>
> .>>> import pdb
> .>>> pdb.True = 0
> .>>> pdb.x = "Darn writeable module dictionaries"
> .>>> from pdb import True
> .>>> True
> 0
> .>>> from pdb import x
> .>>> x
> 'Darn writeable module dictionaries'


If Python really does behave that way, that bug should be fixed immediately.
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      12-14-2004
Raymond Hettinger wrote:
>>Dan Bishop wrote:
>>
>>>>Out of pure curiousity,
>>>>Why wasn't 'While True' optimized also?
>>>
>>>
>>>Probably has something to do with "True" and "False" not being
>>>constants.

>
>
> [Nick Coghlan]
>
>>Yup. Even 'None' only just became a constant in 2.4.
>>
>>I don't know if 'True' and 'False' are in line for similar treatment (there

>
> are
>
>>obvious backwards compatibility issues in doing so).

>
>
> It is unlike to before Py3.0. Making them constants would break the reams of
> compatability code: True, False = (1==1), (1!=1).
>

It was unfortunate that so many people chose to use that for
compatibility, when if they'd used the same code that the win32all
extensions did they could have retained backward compatibility even
across a change to constants:

try:
True
except AttributeError:
True, False = (1==1), (1!=1)

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
 
Reply With Quote
 
Fredrik Lundh
Guest
Posts: n/a
 
      12-14-2004
Steve Holden wrote:

> It was unfortunate that so many people chose to use that for compatibility, when if they'd used
> the same code that the win32all extensions did they could have retained backward compatibility
> even across a change to constants:
>
> try:
> True
> except AttributeError:
> True, False = (1==1), (1!=1)


that doesn't work, though:

$ python2.1 test.py
Traceback (most recent call last):
File "test.py", line 2, in ?
True
NameError: name 'True' is not defined

</F>



 
Reply With Quote
 
Peter Otten
Guest
Posts: n/a
 
      12-14-2004
Fredrik Lundh wrote:

> Steve Holden wrote:
>
>> It was unfortunate that so many people chose to use that for
>> compatibility, when if they'd used the same code that the win32all
>> extensions did they could have retained backward compatibility even
>> across a change to constants:
>>
>> try:
>> True
>> except AttributeError:
>> True, False = (1==1), (1!=1)

>
> that doesn't work, though:
>
> $ python2.1 test.py
> Traceback (most recent call last):
> File "test.py", line 2, in ?
> True
> NameError: name 'True' is not defined



Fixing the exception type doesn't help if the change is implemented like the
constancy of None:

>>> try:

.... None
.... except NameError:
.... None = object()
....
SyntaxError: assignment to None

Another workaround seems viable:

>>> globals()["None"] = "Evil Nun"
>>> None
>>>


Peter

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: while True or while 1 Chris Angelico Python 16 01-24-2012 03:37 AM
while True or while 1 Andrea Crotti Python 0 01-21-2012 01:47 PM
Re: while True or while 1 BartC Python 8 12-28-2010 03:00 PM
Re: while True or while 1 Krister Svanlund Python 6 12-14-2010 04:52 PM
[False,True] and [True,True] --> [True, True]????? bdb112 Python 45 04-29-2009 02:35 AM



Advertisments