Sprite Layer API

[pathunstrom]

Implements a basic layering API.

Sprites can have a layer attribute that should be an integer, but due to implementation details could be a float.

Does not change the renderer as part of this change, will do so in a followup PR.

This is one step on the way to #276

Proposal:

• BaseScene.sprite_layers() which returns all sprites based on their layering order.
• Layers are simple attributes on Sprites.
• You can name layers via BaseScene.named_layers which will default to incrementing each layer number by 1.
• You can have greater control over your layer definition by providing BaseScene.defined_layers as Dict[str, int].
• There is a BaseSprite.default_layer which a Sprite without a layer attribute defaults to. It can be a string or an int as preferred by the end user.

[AstraLuma]

Ok, some takes on this API direction

• So far, we've avoided putting too much logic in BaseSprite and BaseScene and I'm not sure I want that to change? (I assume you want BaseScene.__iter__() to produce sprites in layer order)
• BaseScene.define_layer() is totally against the declarative direction we've been moving in an encouraging
• The thing I had been picturing for string layers is just BaseScene.layers as a list of strings, and the order in the list defines the order of layers? I guess a dict works but it feels clunkier? Maybe I just don't like it because it's not my idea.

[pathunstrom]

So far, we've avoided putting too much logic in BaseSprite and BaseScene and I'm not sure I want that to change?

That's definitely true of BaseSprite, I think BaseScene is just a matter of the only functionality we've needed is container and iteration and lookups.

(I assume you want BaseScene.iter() to produce sprites in layer order)

Yes. That's primarily a backwards compatibility thing: We don't have to change renderer logic by making sure __iter__ is in layer order.

I'm going to ponder on the rest of this. I've got ideas.

[AstraLuma]

ok, so here's the concrete things against implementing ordering in __iter__():

• It makes assigning to properties have a side-effect (and not just a side-effect of "update this cached pre-compute")
• It really doesn't fit with the discussions we've had about non-sprite children

[pathunstrom]

An implementation! Once this is merged, I can start work on both a layering mixin for Sprites and start the work on the Renderer rebuild.

[AstraLuma]

I was expecting the render-side changes to be part of this PR, too? Unless you're immediately planning to do a bunch of renderer work at once.

But what I do see is fine.

[AstraLuma]

One last comment: Did we want to add layer: int = 0 to the base sprite class?

[pathunstrom]

That's reasonable. Will add it.

[AstraLuma]

bors r+

[bors]

Build failed

• Windows python:3.7-windowsservercore-1809

[pathunstrom]

bors retry

[bors]

Build succeeded

• docs
• Linux python:3.6-slim
• Linux python:3.7-slim
• macOS PYTHON:3.6.8
• macOS PYTHON:3.7.2
• pep517
• Windows python:3.6-windowsservercore-1809
• Windows python:3.7-windowsservercore-1809