On Mon, 1 Feb 2010 19:42:38 +0800, René Dudfield <ren...@gmail.com> wrote: > On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall <j...@yahoo.com> wrote: >> In the pygame.sprite module, I think that the Group.has method does not >> behave according to its documentation. The online documentation states >> that Group.has will return True if the Group contains ALL of the given >> sprites. However, in a certain case, Group.has will return True if the >> Group contains ANY of the given sprites. In the following interactive >> code example, grp1.has(spr1, spr2) should return False, but it returns >> True: >> >>>>> import pygame >>>>> spr1 = pygame.sprite.Sprite() >>>>> spr2 = pygame.sprite.Sprite() >>>>> grp1 = pygame.sprite.Group(spr1) >>>>> grp1.has(spr1) >> True >>>>> grp1.has(spr2) >> False >>>>> grp1.has(spr2, spr1) >> False >>>>> grp1.has(spr1, spr2) >> True >>>>> >> >> I'm already in the process of tidying up the pygame.sprite module so >> that it'll make fewer function calls, make fewer hash table look-ups and >> conform to PEP 8 better. So far, I haven't made any changes that could >> break any existing code, but if I change the AbstractGroup.has code to >> match the documentation, then someone's game could break if it depends on >> the incorrect behavior of Group.has. >> >> Would it be OK with all of you if I change Group.has to match the >> documentation? >> >> Thanks, >> Jason >> > > > Best to fix the docs, and add another method. > > Also, there are not full unittests for the sprite module, so it would > be good to get some unittests completed first... so that it would be > sure to catch any errors with your refactoring. >
But the current behavior seems to be inconsistent, i.e. it depends on the order of the sprites. Compare the two last examples Jason provided. Too me, that seems to be a bug. I also just realized an interesting behavior: >>> grp1.has() None shouldn't that either raise an exception or return True like grp1.has([]) does? //Lorenz