New issue
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
math.Vector.scale_to_length docs and add test for display.set_palette() #1972
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍
Thank you for the contribution!
Added test for set_palette().
Most recent change also address: #1754. You should fix the error you are getting right now
and also probably add some more palettes (right now you only check for the empty list) |
Added some more palettes for tests.
bit depth is ignored by set_mode on SDL2, and modern hardware doesn't do 8-bit color-mapped display modes more. This test should just be marked to be skipped on SDL2. |
@robertpfeiffer , So shall I just close the pr and mark it to be skipped on SDL2? |
Don't close the PR, but mark to skip the palette test on SDL2. |
@robertpfeiffer May I know how to do the above ? |
Here is an example of a test that uses a decorator to skip the test when running on SDL2: Lines 152 to 166 in 48571a6
You can change the string in the decorator to describe why this test is being skipped e.g. "set_palette() not supported in SDL2" |
Thanks for the help! |
Changed decorator string to mention why the issue is being skipped in SDL2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, first up thank you for contributing! Looking at the unit test part now and the C code to be tested here:
Lines 2174 to 2239 in 48571a6
#else /* IS_SDLv1 */ | |
static PyObject * | |
pg_set_palette(PyObject *self, PyObject *args) | |
{ | |
SDL_Surface *surf; | |
SDL_Palette *pal; | |
SDL_Color *colors; | |
PyObject *list, *item = NULL; | |
int i, len; | |
int r, g, b; | |
VIDEO_INIT_CHECK(); | |
if (!PyArg_ParseTuple(args, "|O", &list)) | |
return NULL; | |
surf = SDL_GetVideoSurface(); | |
if (!surf) | |
return RAISE(pgExc_SDLError, "No display mode is set"); | |
pal = surf->format->palette; | |
if (surf->format->BytesPerPixel != 1 || !pal) | |
return RAISE(pgExc_SDLError, "Display mode is not colormapped"); | |
if (!list) { | |
colors = pal->colors; | |
len = pal->ncolors; | |
SDL_SetPalette(surf, SDL_PHYSPAL, colors, 0, len); | |
Py_RETURN_NONE; | |
} | |
if (!PySequence_Check(list)) | |
return RAISE(PyExc_ValueError, "Argument must be a sequence type"); | |
len = MIN(pal->ncolors, PySequence_Length(list)); | |
colors = (SDL_Color *)malloc(len * sizeof(SDL_Color)); | |
if (!colors) | |
return NULL; | |
for (i = 0; i < len; i++) { | |
item = PySequence_GetItem(list, i); | |
if (!PySequence_Check(item) || PySequence_Length(item) != 3) { | |
Py_DECREF(item); | |
free((char *)colors); | |
return RAISE(PyExc_TypeError, | |
"takes a sequence of sequence of RGB"); | |
} | |
if (!pg_IntFromObjIndex(item, 0, &r) || | |
!pg_IntFromObjIndex(item, 1, &g) || | |
!pg_IntFromObjIndex(item, 2, &b)) { | |
Py_DECREF(item); | |
free((char *)colors); | |
return RAISE(PyExc_TypeError, | |
"RGB sequence must contain numeric values"); | |
} | |
colors[i].r = (unsigned char)r; | |
colors[i].g = (unsigned char)g; | |
colors[i].b = (unsigned char)b; | |
Py_DECREF(item); | |
} | |
SDL_SetPalette(surf, SDL_PHYSPAL, colors, 0, len); | |
free((char *)colors); | |
Py_RETURN_NONE; | |
} |
it looks like it raises a lot of asserts when it's unhappy with various things, ideally our unit test will check for those things as well as the expected behaviour when everything is going right.
This is stuff like - what happens when the input is not a sequence of RGB triplets (say it is RGBA int quadruplets, a triplet of floats or just a single string or something)? What happens when the display mode is not 8 bit? What if the display module has been quit? Looking at all the stuff in the C code that starts with RAISES should give you a good idea of the sorts of things to check but I expect you can puzzle out how to put wrong stuff into a function call.
To check the asserts are being generated, and that they are the right asserts, you can use the with self.assertRaises():
pattern. for example:
Lines 162 to 163 in 3bb0760
with self.assertRaises(AttributeError): | |
del r.x |
I would also say that in general it is better to create separate pull requests for separate issues as it helps keep things tidy and makes the process of reviewing less confusing. Not a problem for this pull request, but something to bear in mind in the future.
Cheers!
Added some more tests for checking errors using assertRaises.
Tested it on SDL1 on windows and the test passes locally too, looks decent on a look over. Thanks for the contribution! 🎉 👍 |
Changed the docs for pygame math.Vector.2 and math.vector.3 to report that a ValueError is raised instead of ZeroDivisionError when attempting to scale a zero length vector.
fixes #1957