enhance typing for classes arcade.Sprite and arcade.SpriteList

[Snipy7374]

trafficstars

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]

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

[pushfoo]

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]

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 #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 #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