Rect() and FRect() initialization with no arguments

[damusss]

I've added 3 lines of code to the C src to allow Rect and FRect to be made by passing no arguments to them, which will result in a zero rect (x, y, w, h = 0).
The check is so little it should not impact performance at all.

Why did i do this?

• Code speed and quantity: this is an insignificant point but it takes less time/you type less to do pygame.Rect() rather than pygame.Rect(0, 0, 0, 0)
• It feels like it should be possible + prettier to see
• Consistency: the main point: why can i do pygame.Vector2() and i can't do pygame.Rect()? Well, now you do
• Same performace. I am very confident a little sequence length check on the args won't impact performance at all

Other than the C code i modified:

• The _GenericRect class in the rect.pyi stub to include parameterless __init__
• Added some lines of documentation to explain the new behaviour (i'm not the best at documenting, if you'd prefer something different tell me)
• Added a test in rect_test.py to verify the correct initialization of the rect

[novialriptide]

The code looks fine, but is there any use case for this?

[damusss]

The code looks fine, but is there any use case for this? (@novialriptide)

There are some, i think. Maybe you want to create a rectangle and assign it's values later, just like you'd do with a Vector2.
In my UI library you could benefit from this alot. Each element requires a Rect for positioning and sizing, but very often you just want for the element to resize automatically to fill the parent (specified in the style) so you pass an empty rectangle. I use this so much i even made the guiscript.ZeroR() function. Having it built in would be nice, and it would be also consistent as i can do that with pygame.Vector2 as mentioned above. temporary rects, dummy rects, rects made in the __init__/setup and then changed later etc could all be created without parameters. And since the check i'm adding is a simple tuple size check, i'm confident it won't impact performance so it also raises the question "why not?".

[ankith26]

LGTM, thanks for the PR 🎉

I agree with the reasoning to add this API, might not be a huge deal, but does no harm so why not.

I also see that __new__ inits the fields to 0 already, so there's no issue of uninitialised memory at any point

[MyreMylar]

LGTM, and the API makes sense. 👍