Add more __slots__

[gran4]

Sorry for delay

[pushfoo]

I'm hesitant to add __slots__ where it isn't crucial, especially in the UI stack. The primary benefit of slots is saving memory on types which will have a lot of instances, such as Sprite instances. We put __slots__ on BasicSprite rather than Sprite since it's a performance-optimized, limited-capability version of Sprite.

[gran4]

I tried to add slots were it is useful, and not obstructive. The purpose is to stop bad design by people and optimize it as well. I don't think people should be adding attributes to scene anyways or to anything in paths.py.

P.S: Maybe I could take it out of property.py.(Lets be honest, no one should be adding values to a list or a dict anyways so it is more for readability and to warning)

P.P.S: I don't think you should be adding any variable to GUI anyways

[eruvanos]

Property changes within the GUI code looks fine, we already had them in some places and the additional one is fine.

[eruvanos]

@pvcraven any feelings about the slots in Scene? otherwise we can merge

[pushfoo]

tl;dr After further thought, using slots on Scene seems very risky

Scene seems like a good target for subclassing to customize behavior. Using slots on Scene may make such customization much harder. Examples include:

1. Requiring __slots__ to be declared on each subclass, which will confuse beginners
2. Requiring __weakref__ to be included in __slots__ for weak ref compatibility, which could interfere with chunking / room loading implementations
3. Requiring __dict__ to be in slots to add additional values, which would negate memory savings
4. Interference with mixins, which could be useful for different game modes (Parallax vs Non-Parallax after DragonMoffon & I take another look at the Background API)

Disadvantages 1-3 are paraphrased from Fluent Python

As to GUI components, I haven't yet formed a strong opinion. However,

Lets be honest, no one should be adding values to a list or a dict anyways so it is more for readability and to warning

I don't understand what gran4 meant by this. It reads like an attempt to force a more functional style, despite arcade not using that approach. Also, the existence of UserList and UserDict in the Python standard library contradict this idea.

For the A* components, using __slots__ seems fine since:

1. It's intentionally a limited implementation
2. Pathing objects are likely to be created for multiple entities, so seeking memory savings there is probably a good idea.

[eruvanos]

Could you change that?

[pushfoo]

This is much cleaner than before. I have only one change request.

[pvcraven]

I'm not sure what slots gives us by adding it to scene. What problem are we solving?

For the AStar, can we point to speed/memory improvements with using slots? I need to see stats showing the issue and the solution.

[gran4]

I'm not sure what slots gives us by adding it to scene. What problem are we solving?

For the AStar, can we point to speed/memory improvements with using slots? I need to see stats showing the issue and the solution.

I agree, but wrong PR.

[einarf]

I'd say keep slots in types that have many instances. The GUI ones probably makes sense, but do we really end up with that many barrier lists etc?

[einarf]

Keeping the slots on the gui properties