[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Color, unpacking to r,g,b and r,g,b,a - ValueError: too many values to unpack



Hi Lenard,

But are there any situations where one MUST have 3 elements colors only? If not, then just fill in a reasonable default value for times when there isn't an alpha value for the picture.

-Tyler

On Wed, Jun 17, 2009 at 9:31 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
Hi Tyler,

Well, one wants 4 element colors when working with per-pixel-alpha surfaces.

Lenard


Tyler Laing wrote:
Why don't we just fill in a full value of 255 for all the cases where it returns 3 values? If we make every call return four values, and warn about this in the documentation, it becomes very consistent.

-Tyler

On Tue, Jun 16, 2009 at 11:52 PM, Lenard Lindstrom <len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>> wrote:

   René Dudfield wrote:

       On Wed, Jun 17, 2009 at 4:29 PM, Lenard
       Lindstrom<len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>> wrote:
       
           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


             

       hi,

       yeah for example in solarwolf:
        File "solarwolf-1.5/code/gamemenu.py", line 70, in
       load_game_resources
          pal = [(g,g,b) for (r,g,b) in origpal]

        File "solarwolf-1.5/code/objshot.py", line 28, in
       load_game_resources
          for (r,g,b) in origpal]


       hrmm.  I think a 3 element Color subtype might be the way to go.
       Maybe we don't even need a subtype, but just a length property
       that
       can be 1,2,3, or 4?  As you say get_palette(_at) could return
       len 3
       Colors.

       If it could unpack to 3, or 4 depending on the number of
       elements on
       the left, I think I'd prefer that though.



       
   Hi,

   Well yes, but now you are have something that is basically an
   integer array, including the additional overhead.





--
Visit my blog at http://oddco.ca/zeroth/zblog