[Tutor] Livewires questions

Tonu Mikk tmikk at umn.edu
Fri Jul 27 21:54:39 CEST 2007

Luke Paireepinart wrote:
>> def place_robot():
>>     global robot_x
>>     global robot_y
>>     global robot_shape
>>     robot_y = random_between(0,47)-0.5
>>     robot_x = random_between(0,63)-0.5
> I'm not too clear why you're subtracting 0.5 here.
> Doesn't this make the robot's center on the grid lines, rather than 
> having the robot occupy a full square on the grid?
> I guess that's the intended behavior, huh?
This is particular to Livewires module I believe.  I am dealing with the 
circle (player) whose position is defined by the center of the circle 
and a square (robot) whose position is defined by the first two 
coordinates of the square.  I subtract 0.5 here so that when the random 
numbers picked for both the circle and the the square are the same, then 
visually the square is right on top of the circle. 
>>     robot_shape = box(10*robot_x, 
>> 10*robot_y,10*robot_x+10,10*robot_y+10)
>> def move_player():
>>     while 1:
>>         global player_x
>>         global player_y
>>           if 't' in keys:
>>             place_player()
>>             break
> You can't reuse your place_player function here, because you put the 
> initialization (the creation) of the graphics that represent the 
> player _inside_ of the place_player function.  Well, technically you 
> could, but it would be better instead to use move_to(player_shape, x, 
> y) because this doesn't overwrite the old player_shape circle.
> Also, will this work if the player presses "T"?
Ok, I made some progress on the pressing of the "T" key, but it is still 
not entirely correct.  The reason why pressing the 't' key was not 
working initially was because I had omitted the 't' key in the main 
while loop.  As a result, the code never executed the move_player code 
when I pressed the 't' key.  Now if I execute the code above, I get a 
new player circle placed on the grid, but the old player stays there as 
well.  I somewhat expected this because I am not getting rid of the old 
player by calling place_player() function.  How could I eliminate the 
old player circle from the grid?  When I use the move_to(player_shape, 
player_x*10, player_y*10), then the player just stays in the same 
place.  This too I expect, since by using move_to, I am not calling new 
player_x and player_y coordinates.
>>         if '8' in keys:
>>             move_to(player_shape,player_x*10 ,player_y*10 + 10)
>>             player_y = player_y + 1
>>             if player_y > 47:
>>                 player_y = player_y -1
>>             else:
>>                 pass
> 'if' statements don't have to have an 'else' clause.
> else:
>    pass
> is just a waste of 2 lines.  'pass' does nothing, and since the 'else' 
> is not required, you may as well leave it off.
I thought so too.  Part of the problem I had with testing my code was 
that I was using the PythonWin editor that comes with ActivePython.  
Often the PythonWin editor would crash and I wasn't always sure if it 
was because of my code, or because of the editor itself.  It somehow 
seemed that when I had the else: pass in the code, the editor behaved 
better. I have since then started to use IDLE which works much better.  
Thank you for pointing this out BTW.  It takes some of the guess work 
out :-).
> This big block of movement code can be shortened into a few lines.
> I am not sure how much python you know, so if any of this doesn't make 
> sense, let me know.
I am just a newbie in Python.  I like the way you were able to think 
about the code to make the code much more succinct.  I will need to 
learn a bit more before I understand it exactly.  For now, I will try to 
stick with my long, ugly, inefficient code, that I have puzzled together 
and understand.  Your example has not gone wasted however, it will be 
used later when I am more familiar with Python and try to improve my code. 
> Also, I just realized that you're using a while loop inside of your 
> move_player and move_robots function.
> But you only call these functions if you KNOW that a movement key was 
> pressed.
> Basically, this means that one of your 'if' conditions will ALWAYS be 
> true inside of your while: loops, and you'll break out of it.
> The only reason why you might want this is that it would immediately 
> exit as soon as it finds the first key that was pressed, but the
> same thing could be performed using an if-elif chain.  But I doubt you 
> want this to happen.
I will experiment with the if statements there.  Is it better to use 
if-elif chain over the while loop when both can work?
> Also there are other problems - eg. your keys is assigned to the keys 
> that were currently pressed, so if during the time.sleep(0.5) I might
> press and then release a key, and it would be lost in your code.
Yes, I see this when I run the code.  Unfortunately, I don't know how 
else to do it since it is the only way that they show in the Livewires 
exercise.  I am OK it being imperfect for now.
> The code with the changes I mentioned included is attached to this 
> e-mail.
> Also, note that I didn't test this code ( I don't have livewires 
> installed) so if any of it doesn't work, let me know.
I ran the code that you had included, thank you for this.  It did 
produce the player and the robot on the grid, but the keyboard commands 
did not work.  I wasn't entire sure why, but I thought I would let you know.

Thanks again for your help.  If you have suggestions on the 't' key, 
please share them.  This seems to be the one issue preventing me from 
going forward.


More information about the Tutor mailing list