Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GameObjectCollection.add: Behave correctly with inheritance #241

Merged
merged 6 commits into from
Apr 29, 2019

Conversation

nbraud
Copy link
Contributor

@nbraud nbraud commented Apr 27, 2019

  • Make scene tests also use a subclass of TestPlayer.
    This shows that scene.get(kind=TestPlayer) misses (instances of) subclasses.
  • Fix the behaviour in GameObjectCollection.
    Done by adding to all kinds in the MRO. Possibly not the most efficient solution.
  • Refactor tests/scenes/get_methods.

@nbraud nbraud requested a review from a team as a code owner April 27, 2019 19:48
@nbraud
Copy link
Contributor Author

nbraud commented Apr 27, 2019

I had missed a necessary change in GameObjectCollection.remove() (f64dc2b).
Now fixed, but the testsuite for GameObjectCollection is clearly not sufficient.

@@ -48,7 +48,9 @@ def add(self, game_object: Hashable, tags: Iterable[Hashable]=()) -> None:
if isinstance(tags, (str, bytes)):
raise TypeError("You passed a string instead of an iterable, this probably isn't what you intended.\n\nTry making it a tuple.")
self.all.add(game_object)
self.kinds[type(game_object)].add(game_object)

for kind in type(game_object).mro():
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a tricky thing: mro here is going to include BaseSprite, Sprite (the ABC), and object. Are you intending for that to happen or would you rather explicitly exclude those?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't think of any reasons to exclude them (except maybe object?), and there are no documented exceptions about what are valid kinds.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is: what's the difference between self.all and self.kinds[object] under this new functionality?

Copy link
Collaborator

@pathunstrom pathunstrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should improve the test for removal if we're adding this behavior. It didn't catch the change because the change is new functionality and wasn't part of the contract.

I'm glad for the improved functionality, but definitely need to update that test.

Also, I'd rather avoid using the mro in the tests themselves, so add an iterable with the types we should check for somehow.

@nbraud
Copy link
Contributor Author

nbraud commented Apr 27, 2019

I'd rather avoid using the mro in the tests themselves

What do you mean? The tests do not currently use mro().

I'm glad for the improved functionality, but definitely need to update that test.

The tests are already updated; do you mean adding a test that checks that the object is gone from all kinds once removed?

@pathunstrom
Copy link
Collaborator

They don't, but that's also the "easy" way to write the remove test. Was mostly saying not to go that route.

@nbraud
Copy link
Contributor Author

nbraud commented Apr 27, 2019

Done. I'm not particularly ameObjectCollection` testsuite, but fixing it is way out of scope here.

Copy link
Collaborator

@pathunstrom pathunstrom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me.

@nbraud
Copy link
Contributor Author

nbraud commented Apr 27, 2019

OK for merging this as-is, then?

@nbraud
Copy link
Contributor Author

nbraud commented Apr 29, 2019

bors r+

bors bot added a commit that referenced this pull request Apr 29, 2019
241: GameObjectCollection.add: Behave correctly with inheritance r=nbraud a=nbraud

- [x] Make scene tests also use a subclass of `TestPlayer`.
  This shows that `scene.get(kind=TestPlayer)` misses (instances of) subclasses.
- [x] Fix the behaviour in `GameObjectCollection`.
  Done by adding to all kinds in the MRO.  Possibly not the most efficient solution.
- [x] Refactor `tests/scenes/get_methods`.

Co-authored-by: Nicolas Braud-Santoni <nicolas@braud-santoni.eu>
@bors
Copy link
Contributor

bors bot commented Apr 29, 2019

Build succeeded

  • dockerfiles
  • docs
  • Linux Dockerfile:.ci/dockerfiles/python_3.6-slim
  • Linux Dockerfile:.ci/dockerfiles/python_3.7-slim
  • macOS PYTHON:3.6.8
  • macOS PYTHON:3.7.2
  • Windows Dockerfile:.ci/dockerfiles/python_3.6-windowsservercore-1809
  • Windows Dockerfile:.ci/dockerfiles/python_3.7-windowsservercore-1809

@bors bors bot merged commit f707be1 into ppb:master Apr 29, 2019
@nbraud nbraud deleted the scene.get.kinds branch April 29, 2019 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants