Python - if/else statements

Discussion in 'Python' started by dmbkiwi, Jul 11, 2003.

  1. dmbkiwi

    dmbkiwi Guest

    I am new to this group, and relatively new to python programming, however,
    have encountered a problem I just cannot solve through reading the
    documentation, and searching this group on google.

    I have written a theme in python for the superkaramba theme engine on kde
    (see http://netdragon.sourceforge.net - if you are a kde/linux user, it is
    a great visual applet engine). I have uploaded it to www.kdelook.org for
    others to download and use, however, some users are having an issue, which
    to me seems to be very strange.

    Basically the problem is that their version of python is ignoring an
    if/else statement, and I can't understand why. Over 3000 people have
    downloaded the theme, and only 3 people have identified this problem. The
    relevant portion of code is:

    def meterClicked(widget, meter, button):
    #print "meterclick"
    global dayshow, daypicrem, ddon, ddcon, buttonpressed
    if (meter == mainpic) and (button == 1):
    if ddcon == 0:
    if ddon == 1:
    deleteDayDetail(widget, dayshow)
    karamba.redrawWidget(widget)
    createCurrentDetail(widget)
    karamba.redrawWidget(widget)
    else:
    deleteCurrentDetail(widget)
    else:
    for i in range(0,5):
    if (meter == daypicrem) and (button == 1) and (dayshow != i):
    #print "buttonpressed: day" + str(i)
    if ddon == 1:
    deleteDayDetail(widget, dayshow)
    karamba.redrawWidget(widget)
    elif ddcon == 1:
    deleteCurrentDetail(widget)
    karamba.redrawWidget(widget)
    createDayDetail(widget, i)
    karamba.redrawWidget(widget)
    dayshow = i
    #print dayshow
    break
    if (meter == daypicrem) and (button == 1) and (dayshow == i):
    if ddon == 1:
    deleteDayDetail(widget, dayshow)
    karamba.redrawWidget(widget)
    elif ddcon == 1:
    deleteCurrentDetail(widget)
    karamba.redrawWidget(widget)
    dayshow = i
    #print dayshow
    break
    buttonpressed = 1


    What these users are experiencing is that this portion of code is being
    processed, and evaluating all if statements as true, however, as you can
    see, they cannot all be true each time this function is called. Their
    versions of python also ignore the else construct.

    Can anyone shed any light on what might be going on with these users?

    Matt
    dmbkiwi, Jul 11, 2003
    #1
    1. Advertising

  2. On Sat, 12 Jul 2003 07:34:18 +1200, dmbkiwi <> wrote:

    >I am new to this group, and relatively new to python programming, however,
    >have encountered a problem I just cannot solve through reading the
    >documentation, and searching this group on google.
    >
    >I have written a theme in python for the superkaramba theme engine on kde
    >(see http://netdragon.sourceforge.net - if you are a kde/linux user, it is
    >a great visual applet engine). I have uploaded it to www.kdelook.org for
    >others to download and use, however, some users are having an issue, which
    >to me seems to be very strange.
    >
    >Basically the problem is that their version of python is ignoring an
    >if/else statement, and I can't understand why. Over 3000 people have
    >downloaded the theme, and only 3 people have identified this problem. The
    >relevant portion of code is:
    >
    >def meterClicked(widget, meter, button):
    > #print "meterclick"
    > global dayshow, daypicrem, ddon, ddcon, buttonpressed

    # these globals -- where do they come from? What module?
    # Note that each module has its own globals, so is are there different modules
    # that think they're sharing globals but really aren't? There are ways to solve that,
    # but first, is that relevant?

    # Second, are the globals accessible from multiple threads? Are you seeing hard-stuck
    errors or blue-moon errors?

    > if (meter == mainpic) and (button == 1):

    # always here?
    > if ddcon == 0:

    # and here ?
    > if ddon == 1:

    # and here?
    > deleteDayDetail(widget, dayshow)
    > karamba.redrawWidget(widget)
    > createCurrentDetail(widget)
    > karamba.redrawWidget(widget)
    > else:

    # never here, you're saying, right?
    # <snip>
    > else:

    # never here either, right?
    # <snip>
    # get here though?
    > buttonpressed = 1
    >

    I used tabs above to line up (maybe ;-) with your text, but maybe you should
    run your code through tabnanny or something to check for consistent usage.
    I never use tabs (though I use the tab key and gvim puts in 4 space indentation for me ;-)
    so I haven't used the tab checkers, but you might benefit, perhaps.

    >What these users are experiencing is that this portion of code is being
    >processed, and evaluating all if statements as true, however, as you can
    >see, they cannot all be true each time this function is called. Their
    >versions of python also ignore the else construct.
    >
    >Can anyone shed any light on what might be going on with these users?
    >

    I'd check on the globals and threading issues first. Then see about building
    a mousetrap.

    Regards,
    Bengt Richter
    Bengt Richter, Jul 11, 2003
    #2
    1. Advertising

  3. dmbkiwi

    dmbkiwi Guest

    On Fri, 11 Jul 2003 20:33:19 +0000, Bengt Richter wrote:

    > On Sat, 12 Jul 2003 07:34:18 +1200, dmbkiwi <> wrote:
    >


    <snip>
    Thanks for helping me with this.


    >>def meterClicked(widget, meter, button):
    >> #print "meterclick"
    >> global dayshow, daypicrem, ddon, ddcon, buttonpressed

    > # these globals -- where do they come from? What module? # Note that each
    > module has its own globals, so is are there different modules # that think
    > they're sharing globals but really aren't? There are ways to solve that, #
    > but first, is that relevant?


    They don't come from a module, they come from different functions within
    the script. To be honest, I don't think I've ever quite understood
    globals, so I insert them where I think they should go - probably quite
    incorrecly. Will this matter?

    >
    > # Second, are the globals accessible from multiple threads? Are you seeing
    > hard-stuck errors or blue-moon errors?


    Now my newbiness will be evident. Multiple threads? I am not consciously
    creating threads. Should I? Does python automatically create multiple
    threads? What are hard-stuck/blue-moon errors?

    >
    >> if (meter == mainpic) and (button == 1):

    > # always here?

    # yes
    >> if ddcon == 0:

    > # and here ?

    # yes
    >> if ddon == 1:

    > # and here?

    # no
    >> deleteDayDetail(widget, dayshow)
    >> karamba.redrawWidget(widget)
    >> createCurrentDetail(widget)
    >> karamba.redrawWidget(widget)
    >> else:

    > # never here, you're saying, right?

    # always here
    > # <snip>
    >> else:

    > # never here either, right?

    always here
    > # <snip>
    > # get here though?

    # yes
    >> buttonpressed = 1
    >>

    > I used tabs above to line up (maybe ;-) with your text, but maybe you
    > should run your code through tabnanny or something to check for consistent
    > usage. I never use tabs (though I use the tab key and gvim puts in 4 space


    Tabs seem to be fine in the actual code - I think it's the word wrapping
    in either your/my newsreader that is causing problems, but your tab
    positioning is correct.

    > indentation for me ;-) so I haven't used the tab checkers, but you might
    > benefit, perhaps.


    I'm using kate here under KDE/linux. It has syntax highlighting for python, and
    seems to deal with tabs nicely.
    >
    >>What these users are experiencing is that this portion of code is being
    >>processed, and evaluating all if statements as true, however, as you can
    >>see, they cannot all be true each time this function is called. Their
    >>versions of python also ignore the else construct.
    >>
    >>Can anyone shed any light on what might be going on with these users?
    >>

    > I'd check on the globals and threading issues first. Then see about
    > building a mousetrap.


    Why would these affect the interpretation of the if/else. Seems to me,
    that if the if statement evaluates to true, then the else statement should be
    ignored. However, it appears that for these users, python is just
    ploughing right on through, and running the else statement also. Or am I
    missing something. What is a mousetrap?

    Any further help would be greatly appreciated.

    >
    > Regards,
    > Bengt Richter


    --
    Regards
    Matt

    Everyone is more or less mad on one point.
    -- Rudyard Kipling
    dmbkiwi, Jul 12, 2003
    #3
  4. On Sat, 12 Jul 2003 11:16:12 +1200, dmbkiwi <> wrote:

    >On Fri, 11 Jul 2003 20:33:19 +0000, Bengt Richter wrote:
    >
    >> On Sat, 12 Jul 2003 07:34:18 +1200, dmbkiwi <> wrote:
    >>

    >
    ><snip>
    >Thanks for helping me with this.
    >
    >
    >>>def meterClicked(widget, meter, button):
    >>> #print "meterclick"
    >>> global dayshow, daypicrem, ddon, ddcon, buttonpressed

    >> # these globals -- where do they come from? What module? # Note that each
    >> module has its own globals, so is are there different modules # that think
    >> they're sharing globals but really aren't? There are ways to solve that, #
    >> but first, is that relevant?

    >
    >They don't come from a module, they come from different functions within
    >the script. To be honest, I don't think I've ever quite understood
    >globals, so I insert them where I think they should go - probably quite
    >incorrecly. Will this matter?

    It could. It depends. A script or a file (extension may vary, .py, .pyc, etc) that's imported
    is like a big room with a single cork bulletin board. Think of that bulletin board as
    the script's or module's global name space. It's where name tags can be tacked up with names
    associated with objects. You can think of the objects themselves as balloons attached to
    the name tags by strings (the houses have no roofs, so all the balloons occupy space
    someplace high up outside ;-)

    Note that according to this model, when you assign x=y what you
    are doing is finding the y-labled tag and following its string to the associated object-balloon
    and tying a new string to that same balloon, and then attaching that new string to a
    new tag labeled x and tacking this new tag on an appropriate bulletin board, resulting in
    two tags and their strings leading to the same object-balloon.

    Functions are like play houses inside the big room, and they each have their own
    bulletin boards inside, which is each function's local namespace.

    If you write "global xxx" inside a function, you are saying that when you are in that
    playhouse, you will not use the inside private bulletin board for name tags labeled xxx,
    but you will instead reach out and use the bulletin board in the big room. So xxx=123
    means create an integer object-balloon with 123 value and make a tag labeled xxx and
    tie a string from the 123 balloon to that tag, and then reach out and tack the tag to the
    bulletin board in the big room.

    When you leave the playhouse, its inside bulletin board is cleared of name tags (and the
    strings detached). When you enter again, you start with a clean inside board with only
    name tags matching the formal parameter names (if any). If the last string is detached,
    it is grabbed by a balloon collector, who pops it to make sure there is always space in
    the sky for new balloons. Kind of ;-)

    If you don't write "global xxx" inside the function, the rules for name tags labeled
    xxx are different according to whether there's any code _anywhere_ in the function
    that tacks up that name tag (e.g., assigns to that name) or whether the code just
    looks for an existing tag (i.e., just uses it in an expression).

    If there's an assignment anywhere, it's an error to try to use it in an expression
    before the assignment. A legal assignment tacks the tag to the inside bulletin board.
    The balloon and string part is the same story wherever the tag goes.

    If there's no assignment, then the only other ordinary way it can be on the inside bb
    is if it is a parameter name, or it got tacked there by some other code that tacks name tags,
    like def foo... will make a foo name tag (the string goes to a function object), or class Bar...
    which would make a Bar name tag with string to a class object. Those are the main ways.

    If the name tag is not on the inside bb, it could still be on an enclosing playhouse's
    bulletin board (it is now possible to nest playhouses, not just have them all in the big room.
    If the name tag is not found on the bb of the immediately enclosing playhouse, it could be on
    the bb of yet another enclosing playhouse, and so on, until if it is not found on the bb of
    the big common room, it's a name error.

    BTW, the name-tag end of strings can also be tied to some balloons, which may have special
    eyelets taped to them. E.g., tuple-balloons come in variations according to how many fixed
    eyelets they have for attaching strings to other balloons. In the case of tuples, the eyelets
    are single-use. You can't cut and re-tie a single string, you have to make a new tuple-balloon
    and tie what strings you want there. If you cut the last string to a tuple-balloon, the
    baloon collector will grab it and eventually cut all the strings and pop the tuple-balloon,
    maybe right away. He may have secret deals with balloon makers for recycling material, but
    that's his business. List-ballons allow eyelet re-use, and also adding or removing eyelets.
    But every eyelet must have a string leading to some balloon, even if it is the None balloon.

    >
    >>
    >> # Second, are the globals accessible from multiple threads? Are you seeing
    >> hard-stuck errors or blue-moon errors?

    >
    >Now my newbiness will be evident. Multiple threads? I am not consciously
    >creating threads. Should I? Does python automatically create multiple
    >threads? What are hard-stuck/blue-moon errors?

    You shouldn't have multiple threads unless you made them on purpose or used some
    module that did it without your knowing. It should be prominent in the docs if so, though.
    Hard-stuck/blue-moon is not technical terminology ;-) I meant, do you get the error
    every time the code is executed, or only once in a blue moon.
    >
    >>
    >>> if (meter == mainpic) and (button == 1):

    >> # always here?

    > # yes
    >>> if ddcon == 0:

    >> # and here ?

    > # yes
    >>> if ddon == 1:

    >> # and here?

    > # no

    # so at least one if didn't just 'fall through'!
    >>> deleteDayDetail(widget, dayshow)
    >>> karamba.redrawWidget(widget)
    >>> createCurrentDetail(widget)
    >>> karamba.redrawWidget(widget)
    >>> else:

    >> # never here, you're saying, right?

    > # always here

    # very very weird. What evidence are you interpreting to come to these conclusions?
    >> # <snip>
    >>> else:

    >> # never here either, right?

    > always here

    # again weird**n
    >> # <snip>
    >> # get here though?

    > # yes
    >>> buttonpressed = 1
    >>>

    If that is really happening, I wonder if you are somehow executing code from a different version
    or have some kind of mixed-up installation. Or are using incompatible extension modules?
    Do you have multiple versions installed? what are your versions, and what sym links are there?
    And what are the #! lines of your script(s)?
    >> I used tabs above to line up (maybe ;-) with your text, but maybe you
    >> should run your code through tabnanny or something to check for consistent
    >> usage. I never use tabs (though I use the tab key and gvim puts in 4 space

    >
    >Tabs seem to be fine in the actual code - I think it's the word wrapping
    >in either your/my newsreader that is causing problems, but your tab
    >positioning is correct.
    >
    >> indentation for me ;-) so I haven't used the tab checkers, but you might
    >> benefit, perhaps.

    >
    >I'm using kate here under KDE/linux. It has syntax highlighting for python, and
    >seems to deal with tabs nicely.
    >>
    >>>What these users are experiencing is that this portion of code is being
    >>>processed, and evaluating all if statements as true, however, as you can
    >>>see, they cannot all be true each time this function is called. Their
    >>>versions of python also ignore the else construct.
    >>>

    Their versions? Does that mean you are trying to run extensions or .pyc code
    with different version interpreters? That shouldn't work. Python source (.py)
    should work, unless an old interpreter runs into a new feature it doesn't know about.

    >>>Can anyone shed any light on what might be going on with these users?
    >>>

    >> I'd check on the globals and threading issues first. Then see about
    >> building a mousetrap.

    >
    >Why would these affect the interpretation of the if/else. Seems to me,
    >that if the if statement evaluates to true, then the else statement should be
    >ignored. However, it appears that for these users, python is just

    Sure, I didn't really believe what I was reading, I guess. Sorry. I thought
    the condition data was getting clobbered, not the condition machinery.

    >ploughing right on through, and running the else statement also. Or am I
    >missing something. What is a mousetrap?

    By mousetrap I meant some test code inserted to trap the problem mouse, metaphorically speaking.

    >
    >Any further help would be greatly appreciated.

    I guess version clash or some installation corruption looks most likely from here.
    Gotta go...

    Regards,
    Bengt Richter
    Bengt Richter, Jul 12, 2003
    #4
  5. dmbkiwi

    dmbkiwi Guest

    On Sat, 12 Jul 2003 01:58:13 +0000, Bengt Richter wrote:

    > On Sat, 12 Jul 2003 11:16:12 +1200, dmbkiwi <> wrote:
    >
    >>On Fri, 11 Jul 2003 20:33:19 +0000, Bengt Richter wrote:
    >>
    >>> On Sat, 12 Jul 2003 07:34:18 +1200, dmbkiwi <> wrote:
    >>>

    >>
    >><snip>
    >>Thanks for helping me with this.
    >>
    >>
    >>>>def meterClicked(widget, meter, button):
    >>>> #print "meterclick"
    >>>> global dayshow, daypicrem, ddon, ddcon, buttonpressed
    >>> # these globals -- where do they come from? What module? # Note that each
    >>> module has its own globals, so is are there different modules # that think
    >>> they're sharing globals but really aren't? There are ways to solve that, #
    >>> but first, is that relevant?

    >>
    >>They don't come from a module, they come from different functions within
    >>the script. To be honest, I don't think I've ever quite understood
    >>globals, so I insert them where I think they should go - probably quite
    >>incorrecly. Will this matter?

    > It could. It depends. A script or a file (extension may vary, .py, .pyc, etc) that's imported
    > is like a big room with a single cork bulletin board. Think of that bulletin board as
    > the script's or module's global name space. It's where name tags can be tacked up with names
    > associated with objects. You can think of the objects themselves as balloons attached to
    > the name tags by strings (the houses have no roofs, so all the balloons occupy space
    > someplace high up outside ;-)
    >
    > Note that according to this model, when you assign x=y what you
    > are doing is finding the y-labled tag and following its string to the associated object-balloon
    > and tying a new string to that same balloon, and then attaching that new string to a
    > new tag labeled x and tacking this new tag on an appropriate bulletin board, resulting in
    > two tags and their strings leading to the same object-balloon.
    >
    > Functions are like play houses inside the big room, and they each have their own
    > bulletin boards inside, which is each function's local namespace.
    >
    > If you write "global xxx" inside a function, you are saying that when you are in that
    > playhouse, you will not use the inside private bulletin board for name tags labeled xxx,
    > but you will instead reach out and use the bulletin board in the big room. So xxx=123
    > means create an integer object-balloon with 123 value and make a tag labeled xxx and
    > tie a string from the 123 balloon to that tag, and then reach out and tack the tag to the
    > bulletin board in the big room.
    >
    > When you leave the playhouse, its inside bulletin board is cleared of name tags (and the
    > strings detached). When you enter again, you start with a clean inside board with only
    > name tags matching the formal parameter names (if any). If the last string is detached,
    > it is grabbed by a balloon collector, who pops it to make sure there is always space in
    > the sky for new balloons. Kind of ;-)
    >
    > If you don't write "global xxx" inside the function, the rules for name tags labeled
    > xxx are different according to whether there's any code _anywhere_ in the function
    > that tacks up that name tag (e.g., assigns to that name) or whether the code just
    > looks for an existing tag (i.e., just uses it in an expression).
    >
    > If there's an assignment anywhere, it's an error to try to use it in an expression
    > before the assignment. A legal assignment tacks the tag to the inside bulletin board.
    > The balloon and string part is the same story wherever the tag goes.
    >
    > If there's no assignment, then the only other ordinary way it can be on the inside bb
    > is if it is a parameter name, or it got tacked there by some other code that tacks name tags,
    > like def foo... will make a foo name tag (the string goes to a function object), or class Bar...
    > which would make a Bar name tag with string to a class object. Those are the main ways.
    >
    > If the name tag is not on the inside bb, it could still be on an enclosing playhouse's
    > bulletin board (it is now possible to nest playhouses, not just have them all in the big room.
    > If the name tag is not found on the bb of the immediately enclosing playhouse, it could be on
    > the bb of yet another enclosing playhouse, and so on, until if it is not found on the bb of
    > the big common room, it's a name error.
    >
    > BTW, the name-tag end of strings can also be tied to some balloons, which may have special
    > eyelets taped to them. E.g., tuple-balloons come in variations according to how many fixed
    > eyelets they have for attaching strings to other balloons. In the case of tuples, the eyelets
    > are single-use. You can't cut and re-tie a single string, you have to make a new tuple-balloon
    > and tie what strings you want there. If you cut the last string to a tuple-balloon, the
    > baloon collector will grab it and eventually cut all the strings and pop the tuple-balloon,
    > maybe right away. He may have secret deals with balloon makers for recycling material, but
    > that's his business. List-ballons allow eyelet re-use, and also adding or removing eyelets.
    > But every eyelet must have a string leading to some balloon, even if it is the None balloon.
    >


    Crikey, thanks for putting in the time to explain that.
    >>
    >>>
    >>> # Second, are the globals accessible from multiple threads? Are you seeing
    >>> hard-stuck errors or blue-moon errors?

    >>
    >>Now my newbiness will be evident. Multiple threads? I am not consciously
    >>creating threads. Should I? Does python automatically create multiple
    >>threads? What are hard-stuck/blue-moon errors?

    > You shouldn't have multiple threads unless you made them on purpose or used some
    > module that did it without your knowing. It should be prominent in the docs if so, though.
    > Hard-stuck/blue-moon is not technical terminology ;-) I meant, do you get the error
    > every time the code is executed, or only once in a blue moon.


    Hard-stuck (as far as I know).
    >>
    >>>
    >>>> if (meter == mainpic) and (button == 1):
    >>> # always here?

    >> # yes
    >>>> if ddcon == 0:
    >>> # and here ?

    >> # yes
    >>>> if ddon == 1:
    >>> # and here?

    >> # no

    > # so at least one if didn't just 'fall through'!
    >>>> deleteDayDetail(widget, dayshow)
    >>>> karamba.redrawWidget(widget)
    >>>> createCurrentDetail(widget)
    >>>> karamba.redrawWidget(widget)
    >>>> else:
    >>> # never here, you're saying, right?

    >> # always here

    > # very very weird. What evidence are you interpreting to come to

    these conclusions?
    I've put print statements in the script to ensure the script is doing
    what I think it's doing. These were removed for the purpose of posting to
    this group.
    >>> # <snip>
    >>>> else:
    >>> # never here either, right?

    >> always here

    > # again weird**n

    That's why I'm here.
    >>> # <snip>
    >>> # get here though?

    >> # yes
    >>>> buttonpressed = 1
    >>>>

    > If that is really happening, I wonder if you are somehow executing code from a different version
    > or have some kind of mixed-up installation. Or are using incompatible extension modules?
    > Do you have multiple versions installed? what are your versions, and what sym links are there?
    > And what are the #! lines of your script(s)?


    One point that I may not have made clear is that I'm not experiencing this
    behaviour personally with my set up. It is other people using this script
    who are reporting this behaviour. The difficulty I'm having is that it's
    very hard to debug a problem you're not having. I've sent versions of the
    script to these people, with print statements at appropriate points to
    ensure that the script is doing what I think it's doing (in terms of going
    wrong for them), and from the output they send back, the interpreter is
    definitely ignoring the else statement and ploughing through them, even
    though, it's also executed the corresponding if statement.

    >>> I used tabs above to line up (maybe ;-) with your text, but maybe you
    >>> should run your code through tabnanny or something to check for consistent
    >>> usage. I never use tabs (though I use the tab key and gvim puts in 4 space

    >>
    >>Tabs seem to be fine in the actual code - I think it's the word wrapping
    >>in either your/my newsreader that is causing problems, but your tab
    >>positioning is correct.
    >>
    >>> indentation for me ;-) so I haven't used the tab checkers, but you might
    >>> benefit, perhaps.

    >>
    >>I'm using kate here under KDE/linux. It has syntax highlighting for python, and
    >>seems to deal with tabs nicely.
    >>>
    >>>>What these users are experiencing is that this portion of code is being
    >>>>processed, and evaluating all if statements as true, however, as you can
    >>>>see, they cannot all be true each time this function is called. Their
    >>>>versions of python also ignore the else construct.
    >>>>

    > Their versions? Does that mean you are trying to run extensions or .pyc code
    > with different version interpreters? That shouldn't work. Python source (.py)
    > should work, unless an old interpreter runs into a new feature it doesn't know about.


    See above. "Their version" means the user's version, not my version, or
    multiple versions.

    >
    >>>>Can anyone shed any light on what might be going on with these users?
    >>>>
    >>> I'd check on the globals and threading issues first. Then see about
    >>> building a mousetrap.

    >>
    >>Why would these affect the interpretation of the if/else. Seems to me,
    >>that if the if statement evaluates to true, then the else statement should be
    >>ignored. However, it appears that for these users, python is just

    > Sure, I didn't really believe what I was reading, I guess. Sorry. I thought
    > the condition data was getting clobbered, not the condition machinery.
    >
    >>ploughing right on through, and running the else statement also. Or am I
    >>missing something. What is a mousetrap?

    > By mousetrap I meant some test code inserted to trap the problem mouse, metaphorically speaking.
    >
    >>
    >>Any further help would be greatly appreciated.

    > I guess version clash or some installation corruption looks most likely from here.
    > Gotta go...
    >
    > Regards,
    > Bengt Richter


    Thanks anyway. IF you have any other thoughts, let me know.

    --
    Regards
    Matt

    Suffering alone exists, none who suffer;
    The deed there is, but no doer thereof;
    Nirvana is, but no one is seeking it;
    The Path there is, but none who travel it.
    -- "Buddhist Symbolism", Symbols and Values
    dmbkiwi, Jul 12, 2003
    #5
  6. dmbkiwi

    Peter Hansen Guest

    Bengt Richter wrote:
    >
    > It could. It depends. A script or a file (extension may vary, .py, .pyc, etc) that's imported
    > is like a big room with a single cork bulletin board. Think of that bulletin board as
    > the script's or module's global name space. It's where name tags can be tacked up with names
    > associated with objects. You can think of the objects themselves as balloons attached to
    > the name tags by strings (the houses have no roofs, so all the balloons occupy space
    > someplace high up outside ;-)
    > [...]
    > When you leave the playhouse, its inside bulletin board is cleared of name tags (and the
    > strings detached). When you enter again, you start with a clean inside board with only
    > name tags matching the formal parameter names (if any). If the last string is detached,
    > it is grabbed by a balloon collector, who pops it to make sure there is always space in
    > the sky for new balloons. Kind of ;-)


    Almost correct. Actually, the balloons are helium-filled and they simply float
    off into the sky where, after an undefined period of time, but usually instantly,
    they will POP and cease to exist. ;-)

    In Jython, the balloons don't usually POP instantly, but instead float up to the
    stratosphere where a garbage collection airplane flies through and explodes as
    many as it can find, from time to time.

    Even in C Python, balloons which are tied together (since balloons can actually
    have small bulletin board attached too) will actually float around for a while until
    a garbage collection airplane flies through and does its job. Unfortunately,
    some balloons have their own automated popping feature attached (__del__) which
    makes it unsafe for the plane to pop them, so it leaves those alone and it's your
    job to untie their strings from each other so they can pop on their own, or
    be popped by the GC airplane on its next pass.

    > But every eyelet must have a string leading to some balloon, even if it is the None balloon.


    Note also that the None balloon is filled with "super Helium(tm)" as it must stay
    aloft even with so many strings attached! No, wait, the strings are actually
    weightless, right?

    -Peter

    P.S.: Very cute, not to mention accurate, way to describe it, if somewhat involved. :)
    Peter Hansen, Jul 12, 2003
    #6
  7. dmbkiwi

    John Roth Guest

    Is there anything consistent about either the version of
    Python these people are using, or the version of KDE?
    The reason I ask is that there are a lot of different
    versions out there, and while the Python maintainers
    are very good, some of them have subtle bugs. Likewise
    for KDE, and for various distributions.

    I also second Bengt's comment about tabs. Outlook
    Express, for one, eliminates them so your code example
    is simply unreadable. The python standard coding style
    is to use 4 spaces for each level of indentation. Python
    aware editors supply them automatically when you hit
    the tab key.

    John Roth

    "dmbkiwi" <> wrote in message
    news:p...
    > I am new to this group, and relatively new to python programming, however,
    > have encountered a problem I just cannot solve through reading the
    > documentation, and searching this group on google.
    >
    > I have written a theme in python for the superkaramba theme engine on kde
    > (see http://netdragon.sourceforge.net - if you are a kde/linux user, it is
    > a great visual applet engine). I have uploaded it to www.kdelook.org for
    > others to download and use, however, some users are having an issue, which
    > to me seems to be very strange.
    >
    > Basically the problem is that their version of python is ignoring an
    > if/else statement, and I can't understand why. Over 3000 people have
    > downloaded the theme, and only 3 people have identified this problem. The
    > relevant portion of code is:
    >
    > def meterClicked(widget, meter, button):
    > #print "meterclick"
    > global dayshow, daypicrem, ddon, ddcon, buttonpressed
    > if (meter == mainpic) and (button == 1):
    > if ddcon == 0:
    > if ddon == 1:
    > deleteDayDetail(widget, dayshow)
    > karamba.redrawWidget(widget)
    > createCurrentDetail(widget)
    > karamba.redrawWidget(widget)
    > else:
    > deleteCurrentDetail(widget)
    > else:
    > for i in range(0,5):
    > if (meter == daypicrem) and (button == 1) and (dayshow != i):
    > #print "buttonpressed: day" + str(i)
    > if ddon == 1:
    > deleteDayDetail(widget, dayshow)
    > karamba.redrawWidget(widget)
    > elif ddcon == 1:
    > deleteCurrentDetail(widget)
    > karamba.redrawWidget(widget)
    > createDayDetail(widget, i)
    > karamba.redrawWidget(widget)
    > dayshow = i
    > #print dayshow
    > break
    > if (meter == daypicrem) and (button == 1) and (dayshow == i):
    > if ddon == 1:
    > deleteDayDetail(widget, dayshow)
    > karamba.redrawWidget(widget)
    > elif ddcon == 1:
    > deleteCurrentDetail(widget)
    > karamba.redrawWidget(widget)
    > dayshow = i
    > #print dayshow
    > break
    > buttonpressed = 1
    >
    >
    > What these users are experiencing is that this portion of code is being
    > processed, and evaluating all if statements as true, however, as you can
    > see, they cannot all be true each time this function is called. Their
    > versions of python also ignore the else construct.
    >
    > Can anyone shed any light on what might be going on with these users?
    >
    > Matt
    John Roth, Jul 12, 2003
    #7
  8. On Sat, 12 Jul 2003 14:27:33 +1200, dmbkiwi <> wrote:

    >On Sat, 12 Jul 2003 01:58:13 +0000, Bengt Richter wrote:
    >

    [...]
    >> If that is really happening, I wonder if you are somehow executing code from a different version
    >> or have some kind of mixed-up installation. Or are using incompatible extension modules?
    >> Do you have multiple versions installed? what are your versions, and what sym links are there?
    >> And what are the #! lines of your script(s)?

    >
    >One point that I may not have made clear is that I'm not experiencing this
    >behaviour personally with my set up. It is other people using this script

    Is it a single .py file?

    >who are reporting this behaviour. The difficulty I'm having is that it's
    >very hard to debug a problem you're not having. I've sent versions of the
    >script to these people, with print statements at appropriate points to
    >ensure that the script is doing what I think it's doing (in terms of going
    >wrong for them), and from the output they send back, the interpreter is
    >definitely ignoring the else statement and ploughing through them, even
    >though, it's also executed the corresponding if statement.
    >

    I wonder if your script is executed directly by Python. Perhaps it is "sanitized"
    for security reasons before being executed in some context, and it gets glitched,
    in the sanitizing process. If so, could you ask them to put a debug print to
    show what's actually being executed? And ask them how it's being executed
    (ie, exec vs exec in somedir vs execfile vs import and invoke vs whatever they do).
    [...]
    >Suffering alone exists, none who suffer;
    >The deed there is, but no doer thereof;
    >Nirvana is, but no one is seeking it;
    >The Path there is, but none who travel it.
    > -- "Buddhist Symbolism", Symbols and Values
    >

    Cool ;-)

    Regards,
    Bengt Richter
    Bengt Richter, Jul 13, 2003
    #8
  9. dmbkiwi

    dmbkiwi Guest

    On Sat, 12 Jul 2003 23:11:20 +0000, Bengt Richter wrote:

    > On Sat, 12 Jul 2003 14:27:33 +1200, dmbkiwi <> wrote:
    >
    >>On Sat, 12 Jul 2003 01:58:13 +0000, Bengt Richter wrote:
    >>

    > [...]
    >>> If that is really happening, I wonder if you are somehow executing code from a different version
    >>> or have some kind of mixed-up installation. Or are using incompatible extension modules?
    >>> Do you have multiple versions installed? what are your versions, and what sym links are there?
    >>> And what are the #! lines of your script(s)?

    >>
    >>One point that I may not have made clear is that I'm not experiencing this
    >>behaviour personally with my set up. It is other people using this script

    > Is it a single .py file?


    Yes, although it imports a module called karamba (see my original post -
    this is a theme run through a theme engine called superkaramba).

    >
    >>who are reporting this behaviour. The difficulty I'm having is that it's
    >>very hard to debug a problem you're not having. I've sent versions of the
    >>script to these people, with print statements at appropriate points to
    >>ensure that the script is doing what I think it's doing (in terms of going
    >>wrong for them), and from the output they send back, the interpreter is
    >>definitely ignoring the else statement and ploughing through them, even
    >>though, it's also executed the corresponding if statement.
    >>

    > I wonder if your script is executed directly by Python. Perhaps it is "sanitized"
    > for security reasons before being executed in some context, and it gets glitched,
    > in the sanitizing process. If so, could you ask them to put a debug print to
    > show what's actually being executed? And ask them how it's being executed
    > (ie, exec vs exec in somedir vs execfile vs import and invoke vs whatever they do).


    It is being executed through the superkaramba engine (written in c++ I
    believe). Not sure if I, or my users have enough gumption to do the
    debugging you are referring to. I have asked them to execute the script
    which contains a number of print statements to verify that it is ignoring
    the else statement. Is there other debugging info that I should be
    printing when running the script?

    > [...]
    >>Suffering alone exists, none who suffer;
    >>The deed there is, but no doer thereof;
    >>Nirvana is, but no one is seeking it;
    >>The Path there is, but none who travel it.
    >> -- "Buddhist Symbolism", Symbols and Values
    >>

    > Cool ;-)
    >
    > Regards,
    > Bengt Richter


    Glad you liked it. It's just an automated sig generated by the fortune
    program. No conscious thought goes into it :).

    Matt
    dmbkiwi, Jul 13, 2003
    #9
  10. On Sun, 13 Jul 2003 12:30:52 +1200, dmbkiwi <> wrote:

    >On Sat, 12 Jul 2003 23:11:20 +0000, Bengt Richter wrote:
    >
    >> On Sat, 12 Jul 2003 14:27:33 +1200, dmbkiwi <> wrote:
    >>
    >>>On Sat, 12 Jul 2003 01:58:13 +0000, Bengt Richter wrote:
    >>>

    >> [...]
    >>>> If that is really happening, I wonder if you are somehow executing code from a different version
    >>>> or have some kind of mixed-up installation. Or are using incompatible extension modules?
    >>>> Do you have multiple versions installed? what are your versions, and what sym links are there?
    >>>> And what are the #! lines of your script(s)?
    >>>
    >>>One point that I may not have made clear is that I'm not experiencing this
    >>>behaviour personally with my set up. It is other people using this script

    >> Is it a single .py file?

    BTW, since you uploaded it, is there an URL for it?
    >
    >Yes, although it imports a module called karamba (see my original post -
    >this is a theme run through a theme engine called superkaramba).
    >

    Unfortunately that makes me imagine an engine in a theme park, maybe in Argentina ;-P
    IOW I know nothing about theme engines ;-)

    >>
    >>>who are reporting this behaviour. The difficulty I'm having is that it's
    >>>very hard to debug a problem you're not having. I've sent versions of the
    >>>script to these people, with print statements at appropriate points to
    >>>ensure that the script is doing what I think it's doing (in terms of going
    >>>wrong for them), and from the output they send back, the interpreter is
    >>>definitely ignoring the else statement and ploughing through them, even
    >>>though, it's also executed the corresponding if statement.
    >>>

    >> I wonder if your script is executed directly by Python. Perhaps it is "sanitized"
    >> for security reasons before being executed in some context, and it gets glitched,
    >> in the sanitizing process. If so, could you ask them to put a debug print to
    >> show what's actually being executed? And ask them how it's being executed
    >> (ie, exec vs exec in somedir vs execfile vs import and invoke vs whatever they do).

    >
    >It is being executed through the superkaramba engine (written in c++ I
    >believe). Not sure if I, or my users have enough gumption to do the
    >debugging you are referring to. I have asked them to execute the script
    >which contains a number of print statements to verify that it is ignoring
    >the else statement. Is there other debugging info that I should be
    >printing when running the script?

    Maybe write a little test of if/else that doesn't depend on any data
    that you don't control right in the test. E.g., since most of your tests test for == 1 or 0,

    >>> for testval in (0, 1, None, (), [], '', 'x'):

    ... if testval == 0: print '%r==0?'%(testval,),
    ... else: print 'not %r==0?'%(testval,),
    ... if testval == 1: print '%r==1?'%(testval,),
    ... else: print 'not %r==1?'%(testval,),
    ... if testval: print 'if %r?'%(testval,),
    ... else: print 'not if %r?'%(testval,),
    ... print
    ...
    0==0? not 0==1? not if 0?
    not 1==0? 1==1? if 1?
    not None==0? not None==1? not if None?
    not ()==0? not ()==1? not if ()?
    not []==0? not []==1? not if []?
    not ''==0? not ''==1? not if ''?
    not 'x'==0? not 'x'==1? if 'x'?

    Everything should be true (with not prefixes considered).

    If the if/else tests are not working right for local variables, maybe the results will be
    glitched. Also declare a global _with the rest, not a separate line_, say g_testval,
    and do another loop like the above with testval changed to g_testval everywhere.
    If either of these glitch, I'd bet on the global one, but I actually expect them both to
    work. It would make another data point though.

    And just FTHOI, give them a version with 100% space indenting.

    Then the question would be, if these tests work, why don't the tests in the original code.
    We could also ask users to run these tests in some simpler context -- what if they just
    run the above loops in a def test(): (so there's a difference between local and global)
    with nothing more in the script than test() to invoke it? That must work from the console
    command line python, or they are totally FUBAR. But it's a data point on the no-errors side
    of the fence.

    We could then break down the code into painfully primitive steps, and print (where does
    printing go, BTW? is stdout captured for you in a file?) the results of each step. Again
    if something is parsing and potentially modifying the code before executing, giving it
    something dead simple to parse might help. Can someone say if the code is given to the interpreter
    completely unmodified, so we can put that to rest?

    In the meanwhile, if most users have no problem, maybe you have to make a table of user configurations
    -- versions of linux, bsd, python (multiversion? how last upgraded?), libraries? gcc stuff?
    etc. until a pattern emerges as to who has the problems and how they are different.

    Maybe make a little script to capture all that info and make it easy for folks to give it to you.
    (I wouldn't try to make it automatically send an email without their informed consent, though ;-)

    Regards,
    Bengt Richter
    Bengt Richter, Jul 13, 2003
    #10
  11. dmbkiwi

    dmbkiwi Guest

    On Sun, 13 Jul 2003 03:59:53 +0000, Bengt Richter wrote:

    > On Sun, 13 Jul 2003 12:30:52 +1200, dmbkiwi <> wrote:
    >
    >>On Sat, 12 Jul 2003 23:11:20 +0000, Bengt Richter wrote:
    >>
    >>> On Sat, 12 Jul 2003 14:27:33 +1200, dmbkiwi <> wrote:
    >>>
    >>>>On Sat, 12 Jul 2003 01:58:13 +0000, Bengt Richter wrote:
    >>>>
    >>> [...]
    >>> Is it a single .py file?

    > BTW, since you uploaded it, is there an URL for it?


    http://www.kdelook.org/content/show.php?content=6384

    >>
    >>Yes, although it imports a module called karamba (see my original post -
    >>this is a theme run through a theme engine called superkaramba).
    >>

    > Unfortunately that makes me imagine an engine in a theme park, maybe in
    > Argentina ;-P IOW I know nothing about theme engines ;-)


    Same here. Don't know if it's a theme engine or not, but it seemed an
    appropriate description.

    >
    >
    >>
    >>It is being executed through the superkaramba engine (written in c++ I
    >>believe). Not sure if I, or my users have enough gumption to do the
    >>debugging you are referring to. I have asked them to execute the script
    >>which contains a number of print statements to verify that it is ignoring
    >>the else statement. Is there other debugging info that I should be
    >>printing when running the script?

    > Maybe write a little test of if/else that doesn't depend on any data that
    > you don't control right in the test. E.g., since most of your tests test
    > for == 1 or 0,
    >
    > >>> for testval in (0, 1, None, (), [], '', 'x'):

    > ... if testval == 0: print '%r==0?'%(testval,), ... else: print
    > 'not %r==0?'%(testval,), ... if testval == 1: print
    > '%r==1?'%(testval,), ... else: print 'not %r==1?'%(testval,), ...
    > if testval: print 'if %r?'%(testval,), ... else: print 'not if
    > %r?'%(testval,), ... print
    > ...
    > 0==0? not 0==1? not if 0?
    > not 1==0? 1==1? if 1?
    > not None==0? not None==1? not if None? not ()==0? not ()==1? not if ()?
    > not []==0? not []==1? not if []?
    > not ''==0? not ''==1? not if ''?
    > not 'x'==0? not 'x'==1? if 'x'?
    >
    > Everything should be true (with not prefixes considered).
    >
    > If the if/else tests are not working right for local variables, maybe the
    > results will be glitched. Also declare a global _with the rest, not a
    > separate line_, say g_testval, and do another loop like the above with
    > testval changed to g_testval everywhere. If either of these glitch, I'd
    > bet on the global one, but I actually expect them both to work. It would
    > make another data point though.
    >
    > And just FTHOI, give them a version with 100% space indenting.
    >
    > Then the question would be, if these tests work, why don't the tests in
    > the original code. We could also ask users to run these tests in some
    > simpler context -- what if they just run the above loops in a def test():
    > (so there's a difference between local and global) with nothing more in
    > the script than test() to invoke it? That must work from the console
    > command line python, or they are totally FUBAR. But it's a data point on
    > the no-errors side of the fence.
    >
    > We could then break down the code into painfully primitive steps, and
    > print (where does printing go, BTW? is stdout captured for you in a file?)
    > the results of each step. Again if something is parsing and potentially
    > modifying the code before executing, giving it something dead simple to
    > parse might help. Can someone say if the code is given to the interpreter
    > completely unmodified, so we can put that to rest?
    >
    > In the meanwhile, if most users have no problem, maybe you have to make a
    > table of user configurations -- versions of linux, bsd, python
    > (multiversion? how last upgraded?), libraries? gcc stuff? etc. until a
    > pattern emerges as to who has the problems and how they are different.
    >
    > Maybe make a little script to capture all that info and make it easy for
    > folks to give it to you. (I wouldn't try to make it automatically send an
    > email without their informed consent, though ;-)
    >
    > Regards,
    > Bengt Richter


    I'll contact the users, and see if they're up for it.

    Matt
    dmbkiwi, Jul 13, 2003
    #11
  12. dmbkiwi

    dmbkiwi Guest

    On Sun, 13 Jul 2003 17:00:11 +0000, Bengt Richter wrote:

    > On Sun, 13 Jul 2003 16:40:39 +1200, dmbkiwi <> wrote:
    >
    >>On Sun, 13 Jul 2003 03:59:53 +0000, Bengt Richter wrote:
    >>

    > [...]
    >>> BTW, since you uploaded it, is there an URL for it?

    >>
    >>http://www.kdelook.org/content/show.php?content=6384
    >>

    > I get a tar file, but winzip thinks it's broken. Usually it handles them fine.
    >
    > 03-07-13 09:34 507,442 6384-weather_liquid_py-0_7_2_tar.tar
    >
    > [ 9:51] C:\pywk\clp\dmbkiwi>lsm *tar
    > 3912fe9836d69ec9004da899e08e352e 6384-weather_liquid_py-0_7_2_tar.tar
    >
    > That's the MD5 digest, same as from (in case you want to check against a known good you have):
    >
    > [ 9:52] C:\pywk\clp\dmbkiwi>python D:\Python22\Tools\Scripts\md5sum.py 6384-weather_liquid_py-0_7_2_tar.tar
    > 3912fe9836d69ec9004da899e08e352e 6384-weather_liquid_py-0_7_2_tar.tar
    >
    > Regards,
    > Bengt Richter


    It's a *.tar.bz2 file. Does winzip handle bzipped files? Dunno, don't
    use it. If you are interested, I can email the script. Alternatively,
    you could start using linux. Your choice :).
    --
    Regards
    Matt

    If there is any realistic deterrent to marriage, it's the fact that you
    can't afford divorce.
    -- Jack Nicholson
    dmbkiwi, Jul 13, 2003
    #12
    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. Neil Zanella
    Replies:
    8
    Views:
    1,181
    mfmehdi
    Oct 20, 2006
  2. Harry George
    Replies:
    6
    Views:
    372
    Bart Nessux
    Feb 23, 2004
  3. Vince
    Replies:
    12
    Views:
    746
    Martin Gregorie
    Jan 21, 2008
  4. Gergely Kontra
    Replies:
    16
    Views:
    230
    Devin Mullins
    Sep 20, 2005
  5. John Crichton
    Replies:
    6
    Views:
    261
    John Crichton
    Jul 12, 2010
Loading...

Share This Page