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

enhance typing for classes arcade.Sprite and arcade.SpriteList #1867

Open
Snipy7374 opened this issue Aug 8, 2023 · 3 comments
Open

enhance typing for classes arcade.Sprite and arcade.SpriteList #1867

Snipy7374 opened this issue Aug 8, 2023 · 3 comments

Comments

@Snipy7374
Copy link
Contributor

Enhancement request:

arcade.Sprite.draw and arcade.Sprite.register_physic_engine have unannotated arguments (AKA Unknown) as well as arcade.SpriteList.draw

What should be added/changed?

Add type hints for the mentioned above members.

What would it help with?

It'll help users with development and understanding the actual valid type of arguments.

@einarf
Copy link
Member

einarf commented Jan 16, 2024

  • PhysicsEngine could possible have some type/interface
  • Types have been added to draw() in 3.0

@einarf einarf added this to the 3.0 mandatory milestone Feb 18, 2024
@pushfoo
Copy link
Member

pushfoo commented Feb 20, 2024

PhysicsEngine could possible have some type/interface

I've brought this idea up before, but the response I got was that it's hard to standardize on physics engine behavior.

@pushfoo
Copy link
Member

pushfoo commented Feb 22, 2024

TL;DR: SpriteList's typing is better now, but please help with Sprite if you have time and avoid a PhysicsEngine type until after 3.0.

Sprite & SpriteList Typing

  • SpriteList typing is improved by Improve SpriteList typing #1977, but please feel free to take a second look
  • Since physics_engines.py features in our most popular tutorial, I've started cleaning up the types and docstring in it as part of Improve typing and doc for physics engines #1981
  • If any reader has time, please help with getting Sprite and related classes thoroughly annotated
  • I can proof-read any PRs which make doc changes, so don't worry about imperfect doc
  • Otherwise, I'll give sprites a second look after the physics engine typing & doc PR

A Unified Physics Engine Type Probably Needs to Wait

As to the engine type / Protocol, here are my current thoughts after starting on #1981:

  1. There seems to be a repeated pattern of inlined expansion into a list of SpriteLists + properties for checking collision
  2. Abstracting some of that collision checking may clean up code at the price of execution
    3.It's worth reconsidering Scene's layers and structuring and how it interacts with physics engine objects, but probably after 3.0
  3. I haven't looked at the pymunk engine in months, so I I'm not yet sure about what a physics engine Protocol type should look like

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants