Python - if/else statements

[Bengt Richter]

On Sun, 13 Jul 2003 12:30:52 +1200, dmbkiwi <dmbkiwi at yahoo.com> wrote:

>On Sat, 12 Jul 2003 23:11:20 +0000, Bengt Richter wrote:
>
>> On Sat, 12 Jul 2003 14:27:33 +1200, dmbkiwi <dmbkiwi at yahoo.com> 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