GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
See #670 for the initial pull request and https://code.djangoproject.com/ticket/19663 for details.
Fix #19663, text provided to colorize() shouldn't raise exception if …
@charettes : could you please review this one ? I'm not sure you saw that I created a new one and closed the previous one ;)
Fix and test looks good, utils tests pass on python 2.7.3 and 3.2.3 (SQLite), will mark RFC.
Actually the ticket is already marked as RFC. Since I'm not a core committer you'll have to wait until one finds the time to commit your fix.
Is there a reason why you assertTrue instead of assertEqual with colorize result?
The reason is that the purpose of the test is to check that colorize won't raise any exception and not that it returns a specific value.
I was looking for an assertNoException but such a thing doesn't exist afaik.
Still, testing the return of the colorize function would be a nice thing but shouldn't it be done in another test?
Didn't bother to look if it already exists btw.
I can change it to assertEqual if you find it more robust / adequate.
Maybe this approach would be more appropriate:
self.fail("colorise shouldn't raise a type error when text=None")
I also suggest that you add a reference to the trac ticket in the test_colorize_none_text doc, it's faster than running a blame.
Yes it's definitely cleaner this way, good to know that you can self.fail() !
Ack for the trac ticket ref in the doc.
I don't have access to my dev box right now but will update my pull request with all of this as soon as I get my hands on it.
Colorize is not tested currently: http://ci.djangoproject.com/job/Django%20Coverage/HTML_Coverage_Report/_var_lib_jenkins_jobs_Django%20Coverage_workspace_django_utils_termcolors.html#n43
So testing the return value makes sense for me.
Thanks, fixed in 04141c5
Fixed #671 -- Improved setup instructions in README