The new float Rect would not subclass pygame.Rect, as it would have float rather that integer fields. Also, a scaled Surface would automatically return the float Rect.
Having Rect subclass methods return subclass instances is still an issue though. Currently new Rect creation at the C level bypasses the normal Python level methods. I suppose for subclasses, the class call approach can be taken. But I am somewhat uncomfortable about the signature compatibility requirement. It cannot easily be enforced at the declaration level; an incompatible signature would only get caught during a method call. It would also break existing Rect subclasses that depend on a Rect instance being returned, if there are any. It should be noted that builtin Python type methods do not return subclasses either. Anyway, this is getting off track for this thread. But improved handling of subclasses is being considered.
Lenard Lindstrom
On Sep 27, 2011, Toni Alatalo <ant...@kyperjokki.fi> wrote:
On Sep 28, 2011, at 12:28 AM, Greg Ewing wrote:
> However, this would mean that the return value couldn't
> be a standard Rect in this case, as it would have to
I found it nice how anything that has rect attribute, is a Rect :)
> contain floats. This suggests adding a new float-based
> rect class, which would be a useful thing to have
> anyway for passing into the drawing operations.
Hm,
"Though Rect can be subclassed, methods that return new rectangles are not subclass aware. That is, move or copy return a new pygame.Rect instance, not an instance of the subclass. This may change. To make subclass awareness work though, subclasses may have to maintain the same constructor signature as Rect."
does that imply something here? is from http://www.pygame.org/docs/ref/rect.html
> Greg
~Toni
