Making code more pythonic doesn't necessarily mean meeting the PEP8
style guidelines, it just means turning the ideas that you have into
code in the most direct way that best uses the basic features of
Python. For example, python's basic collection, the list, is not an
array and works best when you don't use it as one. When you want to
iterate through all the items in a list, you don't keep track of how
many items there are and step through those numbers to address each
data item.
example_list = [3,4.5,3,2,8.1,39]
for index in range(0,len(example_list),1):
print "The number " + str(example_list[index]) + "is in the list."
That's a roundabout way of working with arrays in lower level languages.
In python, you should iterate through a list with this much more
intuitive structure:
example_list = [3,4.5,3,2,8.1,39]
for value in example_list:
print "The number " + str(value) + "is in the list."
This creates a loop in which each number or object in the list is
substituted for "value" in turn.
Another example: Instead of creating multiple lists to hold multiple
related values of different types, use tuples.
colors = [ ("Blue",0,0,255), ("Red",255,0,0), ("Green",0,255,0),
("White",255,255,255)]
print "Available colors:"
for color in colors:
print color[0]
One of the most important things in python is writing clear and direct
code. Once you're used to it, the barriers between your programming
ideas and actual code will start to fall. Hope this helps you get
started.
-Zack
On Jul 13, 2009, at 6:49 PM, Paulo Silva wrote:
@Zack:
'more pythonic' you mean PEP8? thanks a lot fixing the code, and
helping me sensiblelizing a habit on this codiing way
one thing i were trying to do is making the collision changing a
variable for the colour, and using 'screen.fill(collisioncolour)' just
once, as seeing the logic of your last code
http://pastebin.com/m25df2e2b , the result were not that different
one thing impressed me is that your last code seems to be much more
fluid - what you did on that?
on the other side, i'm still very far of understanding stuff like
'elif' or 'pygame.sprite.Group' - i am really having lots of
difficulties trying to understand how Pygame sprite groups work...
again, thanks a lot! :)
On 7/13/09, Zack Schilling <[email protected]> wrote:
It only shows one sprite because you're filling the screen each and
every time you draw one. That's also part of the reason why your
code
is so incredibly slow.
Delete this line:
screen.fill(0x998877)
And move it before the for loop:
screen.fill(0x998877)
for i in range (0,amnt,1):
spridr[snum[i]].left=xpos[i]
spridr[snum[i]].top=ypos[i]
But forget all that, what's much more important is writing code in a
more pythonic way. Look at this rewrite of your code. It's not
perfect
(and still does some things strange ways for the sake of simplicity
and retaining the old structure) but it should help you a lot.
http://pastebin.com/m25df2e2b
-Zack
On Jul 13, 2009, at 3:12 PM, Paulo Silva wrote:
well, the exact answer i can say is 'yes and no'... ;)
the 'yes' is finally i can start understanding how collisions
works on
pygame, and this is truly wonderful! thank you!
the 'no' is, when i did use 'if' over coordinates and size
calculations instead of collisions - http://pastebin.com/f38dfd442 -
it also shown just one sprite instead of from 'amnt' variable (i
used
to try between 32 and 128), and performed hugelly slow as well... -
this is concerning me when i had some ideas on coding games with
some
complexity on sprite ammounts (like doing some danmaku experimental
stuff or something in this way...)
for me were a surprise why both http://pastebin.com/m1e1c7c94 and
http://pastebin.com/f38dfd442 shown only one sprite - very weird...
overally, your correction will help me coding simpler snippets
thanks! :) (and thanks also confirming subsurfaces are fine for
collisions - i'm still very newbie on Pygame! :) )
On 7/13/09, Zack Schilling <[email protected]> wrote:
Well, this version runs. I'm not sure if it's doing what you want
but
it does make a windows and draws some stuff. The subsurface splits
are
correct. I tried to make minimal corrections.
http://pastebin.com/m1e1c7c94
-Zack
On Jul 13, 2009, at 11:47 AM, Paulo Silva wrote:
@Zack - what i wanted were change the background colour to #FF0000
only when the sprites 0 and 1 collides - anyway, sorry this code
is
not PEP8, and using abbreviated variable names - i came from
hobbystic
80's ansi-basic , where i were hugelly one-liner, and variable
names
only took 1 or 2 characters that time - i have deep bad habits
from
that time, and learning PEP8 is still a huge barrier for me - be
welcome on breaking lines at ';' or rewriting variable names, if
you
want...
@Henrique, if you can help fixing http://pastebin.com/f524a8cf2
would
be great - i understand what you were saying from the error
message,
but i don't have any idea about the solution for that... - what i
coded there were the closest i could imagine as possible for
having
that working... - i even tried to avoid all default sprite
collision
methods from pygame, and only using position and size calculations
for
collisions (outside of any def or class - i'm trying to avoid them
on
snippets like this), but the code became hugelly slow....
thank you all!
On 7/13/09, Henrique Nakashima <[email protected]>
wrote:
Traceback (most recent call last):
File "col.py", line 52, in <module>
collide=pygame.sprite.collide_rect(sprid[0],sprid[1])
File "C:\Python25\lib\site-packages\pygame\sprite.py", line 1146,
in
collide_r
ect
return left.rect.colliderect(right.rect)
AttributeError: 'pygame.Surface' object has no attribute 'rect'
This error happens because you are passing Surfaces to
pygame.sprite.collide_rect, not Sprites.
On Mon, Jul 13, 2009 at 12:27, Zack Schilling
<[email protected]>wrote:
I tried to read and correct your code, but I have no idea at all
what's
going on. It's written like C++ transposed directly into python,
which is
confusing. It doesn't help that there are no comments at all and
the
variable names are cryptic. A big problem seems to be simply
feeding wrong
object types to all the functions. You're sending sprites to
blitters and
rects to the sprite collide.
I'll have a go at understanding what you want to do and making
it
work,
but
I make no promises. If I can get that far, I'll also rewrite
it in
a much
more pythonic way. Then you can compare the two and learn much
better
practices when working in python.
-Zack
On Jul 13, 2009, at 8:03 AM, Paulo Silva wrote:
hi!
well, for me finding a good pygame snippet with sprite
collision
(and
simple to understand) is like finding a needle in a haystack...
but when i try do on my own, i get this:
Traceback (most recent call last):
File "_spritesheetexample15b4_difsiz_collision.py", line 47, in
<module>
collide
=pygame.sprite.collide_rect(spridr[0].rect,spridr[1].rect)
AttributeError: 'pygame.Rect' object has no attribute 'rect'
the example is: http://pastebin.com/f524a8cf2
all suggestions are welcome! (be welcome also fixing that
pastebin,
and sending us the pastebin url with the fixes! ;) ) - sorry
it's
not
PEP8 yet... :/
thanks! ;)
On 7/13/09, René Dudfield <[email protected]> wrote:
On Mon, Jul 13, 2009 at 7:32 AM, Paulo Silva <[email protected]
wrote:
this reference i know from a long time, and figured out easily
there
were the exact methods to be used - the problem is i couldn't
have a
snippet working only following that - on my oppinion on that
referenence, each pygame method should have a working snippet
to be
tried out - for me is easier to work on tiny snippets, just
like with
lego bricks
Hi,
pygame comes with examples. Either use those, or use the code
search
button
next to each method, to search through all the projects on the
internet
that
use pygame. There's 238 results for spritcollide for example.
cu,
