Python - if/else statements

[Bengt Richter]

On Sat, 12 Jul 2003 11:16:12 +1200, dmbkiwi <dmbkiwi at yahoo.com> wrote:

>On Fri, 11 Jul 2003 20:33:19 +0000, Bengt Richter wrote:
>
>> On Sat, 12 Jul 2003 07:34:18 +1200, dmbkiwi <dmbkiwi at yahoo.com> 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