Only update Python palette when loading an image if rawmode was different

[radarhere]

After loading the palette into the C image in load(),

Pillow/src/PIL/Image.py

Lines 889 to 891 in ec40c54

	# realize palette
	mode, arr = self.palette.getdata()
	self.im.putpalette(self.palette.mode, mode, arr)

the Python palette may also be updated with what the C image now reports.

Pillow/src/PIL/Image.py

Lines 901 to 903 in ec40c54

	self.palette.palette = self.im.getpalette(
	self.palette.mode, self.palette.mode
	)

This PR suggests only updating the Python palette when the palette rawmode is different to the mode. The rest of the time, the palette data will be unchanged by the trip through the C layer, and this is redundant.

[radarhere]

This is an alternative fix to #9308. When the Python palette was updated, it was being set to bytes, and failing a type hint assertion.

I've updated a test from #1985 to cover this scenario in our test suite.

[markmentovai]

I don’t think that this is the best possible test for the fix, because it doesn’t actually draw anything. You’re only giving a single coordinate pair to ImageDraw.line.

I don’t know that it’s great that ImageDraw.line even accepts this since it’s (almost) a functional no-op, but I’m assuming that you wouldn’t want to change it now because existing code might be reliant on this behavior. (But that existing code might be broken?) Regardless, it’s not in scope for this change.

But really, as long as ImageDraw.line might accept a single coordinate pair, or even zero coordinate pairs (which it also accepts), it’d still be well within its rights to not alter the palette given that there’s nothing to draw in these cases. That it does now is maybe even a little unexpected, and it’s why I referred to the operation as “almost” a no-op above. At best, it’s probably just a side effect of the implementation, and nothing that anyone (including this test) should rely on.

I’m not sure what the original form of this test, test_valueerror, was intended to achieve, but if it’s important to get test coverage of the single coordinate pair ImageDraw.line case, I don’t think it’s prudent to replace that test with something that tests the fix for the behavior originally reported in #9308.

It would be best if the test for this palette did actual drawing that altered the image, such as by providing (at least) 2 unequal coordinate pairs to ImageDraw.draw, or by using ImageDraw.point as the test I originally proposed in #9308 did.

Even better if the test further asserted that the draw operation had an effect on the image, not just the palette, because if it’s possible for the image to not change, it’s also reasonable that the palette might not.

[radarhere]

I've updated the test to use point() and to check what is drawn afterwards.

I'm somewhat inclined to leave existing tests as they are, so I haven't adjusted the original code, but in practical terms, no, I don't think the use of line() is important here, and could easily be replaced with point().