while 1 vs while True

Discussion in 'Python' started by Timothy Fitz, Dec 13, 2004.

  1. Timothy Fitz

    Timothy Fitz Guest

    [ 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?
     
    Timothy Fitz, Dec 13, 2004
    #1
    1. Advertising

  2. Timothy Fitz

    Dan Bishop Guest

    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.'
     
    Dan Bishop, Dec 13, 2004
    #2
    1. Advertising

  3. Timothy Fitz

    Nick Coghlan Guest

    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 | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Dec 13, 2004
    #3
  4. > 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
     
    Raymond Hettinger, Dec 14, 2004
    #4
  5. Timothy Fitz

    Paul Rubin Guest

    "Raymond Hettinger" <> 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.
     
    Paul Rubin, Dec 14, 2004
    #5
  6. Timothy Fitz

    Nick Coghlan Guest

    Paul Rubin wrote:
    > "Raymond Hettinger" <> 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 | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Dec 14, 2004
    #6
  7. Timothy Fitz

    Paul Rubin Guest

    Nick Coghlan <> 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.
     
    Paul Rubin, Dec 14, 2004
    #7
  8. Timothy Fitz

    Steve Holden Guest

    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
     
    Steve Holden, Dec 14, 2004
    #8
  9. 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>
     
    Fredrik Lundh, Dec 14, 2004
    #9
  10. Timothy Fitz

    Peter Otten Guest

    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
     
    Peter Otten, Dec 14, 2004
    #10
  11. Timothy Fitz

    Steve Holden Guest

    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
    >

    Well, OK. But, lest people should think the worse of win32all because of
    my laziness in not finding the exact quote, I should point out that the
    code I meant to quote actually says:

    # Pre 2.2.1 compat.
    try: True, False
    except NameError: True = 1==1; False = 1==0

    I believe this should work for all versions up to 2.4, and would also
    work with a 2.5 that made True and False constants. But if anyone can
    prove me wrong it would be you ... :)

    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
     
    Steve Holden, Dec 14, 2004
    #11
  12. Timothy Fitz

    Steve Holden Guest

    Peter Otten wrote:

    > 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
    >

    Aargghh, so the knowledge of None's constancy appears to extend into the
    syntax analysis. Damn, that means my last posting was wrong as well.
    Should have checked this all out in 2.4 before asserting things that
    weren't true, I suppose.

    Interestingly the same error occurs even when attempting sideways access:

    Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import __builtin__
    >>> __builtin__.None = "Rhubarb"

    SyntaxError: assignment to None

    I'm not sure that I actually agree with the classification of this as a
    syntax error - there's actually nothing wrong with the syntax at all in
    either of these two cases.

    > Another workaround seems viable:
    >
    >
    >>>>globals()["None"] = "Evil Nun"
    >>>>None


    Clearly the behavior of None has been fairly radically altered if you
    can't see a None in globals any more:

    Python 2.3.4 (#53, Oct 18 2004, 20:35:07) [MSC v.1200 32 bit (Intel)] on
    win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> globals()["None"] = "An Evil String"
    >>> None

    'An Evil String'

    Of course this is all in line with the intention that programmatic
    references to None should always pick up the singleton instance of type
    NoneType.

    It's also quite interesting that the Python 2.4 documentation actually
    says (in section 2.5 of the Python Library reference" that False and
    True are constants, when they clearly aren't "as constant as None":

    Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import __builtin__
    >>> __builtin__.True = 23
    >>> __builtin__.True

    23
    >>> True

    23
    >>> __builtin__.None = 23

    SyntaxError: assignment to None
    >>>


    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
     
    Steve Holden, Dec 14, 2004
    #12
  13. Steve Holden wrote:
    > Interestingly the same error occurs even when attempting sideways access:
    >
    > Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
    > win32
    > Type "help", "copyright", "credits" or "license" for more information.
    > >>> import __builtin__
    > >>> __builtin__.None = "Rhubarb"

    > SyntaxError: assignment to None


    And in assignment to something that just looks like it could be None:

    >>> class C(object):

    .... def __init__(self):
    .... self.None = None
    Traceback ( File "<interactive input>", line 3
    SyntaxError: assignment to None (<interactive input>, line 3)

    Another Steve
     
    Steven Bethard, Dec 14, 2004
    #13
  14. Steve Holden wrote:
    > # Pre 2.2.1 compat.
    > try: True, False
    > except NameError: True = 1==1; False = 1==0
    >
    > I believe this should work for all versions up to 2.4, and would also
    > work with a 2.5 that made True and False constants. But if anyone can
    > prove me wrong it would be you ... :)


    Seems like it might work, though we couldn't have the SyntaxError like
    we do for None:

    >>> try:

    .... None
    .... except NameError:
    .... None = 0
    Traceback (SyntaxError: assignment to None

    Note that even though I don't actually enter the except block, I still
    get a SyntaxError.

    Another Steve
     
    Steven Bethard, Dec 14, 2004
    #14
  15. Timothy Fitz

    Nick Coghlan Guest

    Paul Rubin wrote:
    > Nick Coghlan <> 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.


    I tried it out in the 2.4 interpreter before posting it - it certainly does
    behave that way.

    And some test frameworks do make use of the capability to inject behaviour into
    the module under test (e.g. the one mentioned here:
    http://mail.python.org/pipermail/python-list/2003-April/156301.html).

    This is behaviour which has been around for a while - and breaking such expected
    behaviour gratuitously isn't acceptable.

    PEP 267 discusses a way of speeding access to globals/builtins without giving up
    the external binding of names.

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Dec 15, 2004
    #15
  16. Timothy Fitz

    Peter Hansen Guest

    Paul Rubin wrote:
    > Nick Coghlan <> 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.


    (My ISP's news server seems to be dropping messages, so I didn't
    see Nick's original message above, nor perhaps the message he
    was replying to. I hope that doesn't matter to my reply...)

    Paul, what is wrong with the above behaviour, that you believe it
    to indicate a bug?

    As Nick showed in his following reply, there are certainly
    people who make use of this behaviour, and I don't believe
    it could be duplicated with any other existing feature of
    Python. Removing it would, for but one example, cripple
    my ability to do effective automated testing in my field
    of work.

    -Peter
     
    Peter Hansen, Dec 15, 2004
    #16
  17. Timothy Fitz

    Terry Reedy Guest


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


    > If Python really does behave that way, that bug should be fixed
    > immediately.


    The fact that the attributes of Python modules, like those of classes (and
    functions and instances) are externally mutable is a design feature, not a
    bug. (Call Python's dynamicity a design bug if you will, but that is
    different from a plain 'bug'.)

    This allows, for instance, programs to have an in-memory blackboard module
    with across-module variables that all other modules can write to as well as
    read. This design has been recommended several times on this list. We
    would, of course, all agree that having modules arbitrarily poking each
    others attributes is a bad idea. Indeed, that is the rationale for
    isolating all such pokes into a single blackboard module.

    Terry J. Reedy
     
    Terry Reedy, Dec 15, 2004
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bdb112
    Replies:
    45
    Views:
    1,373
    jazbees
    Apr 29, 2009
  2. Krister Svanlund

    Re: while True or while 1

    Krister Svanlund, Dec 12, 2010, in forum: Python
    Replies:
    6
    Views:
    246
    Arnaud Delobelle
    Dec 14, 2010
  3. BartC

    Re: while True or while 1

    BartC, Dec 16, 2010, in forum: Python
    Replies:
    8
    Views:
    277
    Francesco
    Dec 28, 2010
  4. Andrea Crotti

    while True or while 1

    Andrea Crotti, Jan 21, 2012, in forum: Python
    Replies:
    0
    Views:
    153
    Andrea Crotti
    Jan 21, 2012
  5. Chris Angelico

    Re: while True or while 1

    Chris Angelico, Jan 21, 2012, in forum: Python
    Replies:
    16
    Views:
    486
    Steven D'Aprano
    Jan 24, 2012
Loading...

Share This Page