René Dudfield wrote:
Hi,
one issue with the new Color type is unpacking to r,g,b or r,g,b,a.
In some places Color is assumed to return (r,g,b) and others
(r,g,b,a), and now many things return a Color rather than a tuple.
So I want to change Color to unpack to r,g,b,a or r,g,b.
r,g,b = pygame.Color(1,2,3,4)
r,g,b,a = pygame.Color(1,2,3,4)
Anyone have an idea how this can work? Either in C or python?
This is to keep backwards compatibility.
cheers,
Hi René,
Are there cases where this is breaking code? For the most part I believe
Pygame functions returned 4-tuples. So Color is just pretty much a
drop-in replacement. If a program is using tuples to declare color
values then the size is already known and unpacking is not a problem. It
is Surface.get_palette and get_palette_at, which originally returned
3-tuples, where we run into problems. So here are the choices I see.
One, just accept that the new get_palette and get_palette_at will break
things, just as any program that tries to use a color return value as a
dictionary key will now break. How many programs actually use color
palettes anyway? Two, give Color a size property. If alpha is set None
it becomes length 3. But then how does one represent this internally
without adding another field to the Color C structure? Declare the color
component values as C ints? Three, create a new Color subtype of length
3 having a fixed alpha of 255. I'm not happy with any of the choices but
prefer three. Any other ideas?
Lenard