[reportlab-users] Buglet and fix in HexColor (2.6 and probably before)

[Andy Robinson]

Dinu, a belated thanks for this.  We've been very busy the past week,
but will address this soon.

I might hold off until next week as we have some new staff starting
and it would be good instruction in the process of reproducing bugs,
writing tests and fixing them.

I'm also happy to use your tracker.    At some point, a move to
mercurial is on the cards as well, but probably 3-6 months away; it
needs to be timed with a move of a bunch of client projects to
mercurial.

- Andy

On 18 January 2013 17:50, Dinu Gherman <gherman at darwin.in-berlin.de> wrote:

> Am 17.01.2013 um 19:18 schrieb Tim Roberts:

>

>> Dinu Gherman wrote:

>>> I noticed a bug in reportlab.lib.colors.HexColor when actually using the

>>> alpha parameter, e.g.:

>>>

>>> In [1]: from reportlab.lib.colors import HexColor

>>> In [2]: HexColor(16777215, alpha=0.5)

>>

>> The "alpha" parameter is just a Boolean that identifies whether or not

>> alpha is present in the first parameter.  So, to get the effect you

>> asked for, you'd want:

>>    HexColor( 0x80ffffff, alpha=True )

>

> Correct. I was in a hurry when reporting this, maybe also the effect of

> not having a public bug tracker, as described here:

>

>   http://www.reportlab.com/software/opensource/rl-toolkit/faq/#3.1

>

> Still I think the signature is slightly misleading, even with a default

> value for alpha=False, because color objects also have an alpha attribute

> and one would assume the parameter to be stored as that attribute.

>

> And then there are different classes in this module with an alpha keyword

> parameter meaning either a value in [0..1], [0..100] or [True, False]. In

> code I write I prefer the real intent being better expressed with names

> like is_alpha or has_alpha for such Booleans.

>

>> The root of the problem is one missing set of parens around the

>> (val>>24)&0xff term, which your patch adequately corrects.

>

> Yes. I was looking now into reportlab-2.6/tests/test_lib_colors.py which

> doesn't contain such basic tests for creating color instances. And it

> seems like it does not use unittest properly since it uses many plain

> assert statements and not unittest.TestCase.assertX methods... Maybe that's

> because it could also be run with py.test? Unfortunately not:

>

> $ py.test -s test_lib_colors.py

> ========================================= test session starts =========================================

> platform darwin -- Python 2.7.3 -- pytest-2.3.4

> collected 0 items / 1 errors

>

> =============================================== ERRORS ================================================

> _________________________________ ERROR collecting test_lib_colors.py _________________________________

> test_lib_colors.py:7: in <module>

>>   setOutDir(__name__)

> /opt/lib/python2.7/site-packages/reportlab/lib/testutils.py:48: in setOutDir

>>           assert name=='__main__',"setOutDir should only be called in the main script"

> E           AssertionError: setOutDir should only be called in the main script

> ======================================= 1 error in 0.09 seconds =======================================

>

> Anyway...

>

> Regards,

>

> Dinu

>

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users




-- 
Andy Robinson
Managing Director
ReportLab Europe Ltd.
Thornton House, Thornton Road, Wimbledon, London SW19 4NG, UK
Tel +44-20-8405-6420