-
-
Notifications
You must be signed in to change notification settings - Fork 198
Description
I recently tried to unpack a Circle object similar to how I would unpack a Rect.
I would suggest allowing Circle, Line, and any other planned objects in the pygame.geometry module to allow for unpacking.
>>> c = Circle(0, 0, 5)
>>> x, y, r = c
Traceback (most recent call last):
File "<python-input-3>", line 1, in <module>
x, y, r = c
^^^^^^^
TypeError: cannot unpack non-iterable pygame.geometry.Circle object
or x, y, d, d = c if we really want to go for uniformity between shapes, but I think x, y, r is probably best.
I would also suggest adding centerx and centery and for that matter all off the same properties from Rect as best they fit.
>>> c.center
(0.0, 0.0)
>>> c.centerx
Traceback (most recent call last):
File "<python-input-3>", line 1, in <module>
c.centerx
AttributeError: 'pygame.geometry.Circle' object has no attribute 'centerx'. Did you mean: 'center'?
>>> c.centery
Traceback (most recent call last):
File "<python-input-4>", line 1, in <module>
c.centery
AttributeError: 'pygame.geometry.Circle' object has no attribute 'centery'. Did you mean: 'center'?
I know that some of these properties seem silly to add but for the sake of consistency they should match as best as possible even if centerx just is an alias for .x.
The use case I see for this is allowing multiple shapes in a list to be iterated over without need to check what kind of shape they are. I could just do a for loop and get for example the shape.centerx for each shape in the list and not have to care if Circles are in the list. Same with width and height, just alias them to return diameter.
I'd also love to see some shorthand aliases for .top, .bottom, .left, and .right being .t, .b, .l, and .r. but this is probably too complicated.
Anyways, let me know what you think. Maybe this is all planned already.