Re: [pygame] BUG:? color incompatibility in pygame 1.8.1release versus 1.7.1release

2008-08-18 Thread Brian Fisher 
Regardless of backwards compatibility issues, having a default alpha value
of 0 just seems completely wrong to me, and completely non-intuitive.
largely because in a 24-bit context (like on the web), I would always be
writing #RRGGBB, and would never even consider adding in an alpha. So my
brain has naturally gotten a lot of experience associating specifying RGB
with no A as meaning a solid color.

meaning I would definitely say having a default alpha of 0 in any case is a
bug. period.

On Sun, Aug 17, 2008 at 7:45 PM, Nicholas Dudfield [EMAIL PROTECTED]wrote:

 I will update the tests.

 If the new Color.__doc__ claims case insensitivity then I will put in a
 failing test.

 The author of the module wrote some tests for webstyle arguments to the
 Color constructor that explicitly tested for 0 as the default alpha so I'm
 not sure there.

 Actually there seems to be some internal inconsistencies as:

 In [2]: pygame.Color(0,0,0)
 Out[2]: (0, 0, 0, 255)

 In [3]: pygame.Color(#00)
 Out[3]: (0, 0, 0, 0)

 What is the policy regarding backwards compatibility with 1.7.1? Should I
 put in tests for the old functions as well?

 Summary:

 Color construction from string, case insensitivity
 WebStyle default alpha
 Module level functions

Re: [pygame] BUG:? color incompatibility in pygame 1.8.1release versus 1.7.1release

2008-08-17 Thread Lenard Lindstrom 
According the the pygame.color.Color doc string the alpha portion is 
optional: With the hex color formatting you may optionally include an 
alpha value, the formatting is 0xRRGGBBAA. You may also specify a hex 
formatted color by starting the string with a '#'. In Pygame a three 
element color is understood to have an alpha of 255. This is the case 
elsewhere in the package. It is consistent with non per-pixel alpha 
colors. A zero alpha is not:


 s = pygame.Surface((1, 1), pygame.SRCALPHA, 32)
 s.get_at((0, 0))
(0, 0, 0, 0)
 s.fill((1, 2, 3))
rect(0, 0, 1, 1)
 s.get_at((0, 0))
(1, 2, 3, 255)

Also in the doc string: The color name used is case insensitive and 
whitespace is ignored.



pygame.color.Color(red)

(255, 0, 0, 255)

pygame.color.Color(Red)

Traceback (most recent call last):
 File stdin, line 1, in module
ValueError: invalid color name

So case insensitivity in color names is gone as well.

Finally the add, multiply and subtract functions are missing from the 
pygame.color module. These are now operations on the new Color type. Yet 
existing game code would still use them. And the functions worked with any 
integer sequence type.



Lenard


claudio canepa wrote:

color incompatibility in pygame 1.8.1release versus 1.7.1release
 
 import pygame

 print pygame.version.ver
1.8.1release
 c=pygame.color.Color('#00')
 print c
(0, 0, 0, 0)



 import pygame
 print pygame.version.ver
1.7.1release
 c = pygame.color.Color('#00')
 print c
(0, 0, 0, 255)

Re: [pygame] BUG:? color incompatibility in pygame 1.8.1release versus 1.7.1release

2008-08-17 Thread Nicholas Dudfield 
I will update the tests.

If the new Color.__doc__ claims case insensitivity then I will put in a
failing test.

The author of the module wrote some tests for webstyle arguments to the
Color constructor that explicitly tested for 0 as the default alpha so I'm
not sure there.

Actually there seems to be some internal inconsistencies as:

In [2]: pygame.Color(0,0,0)
Out[2]: (0, 0, 0, 255)

In [3]: pygame.Color(#00)
Out[3]: (0, 0, 0, 0)

What is the policy regarding backwards compatibility with 1.7.1? Should I
put in tests for the old functions as well?

Summary:

Color construction from string, case insensitivity
WebStyle default alpha
Module level functions