Added type hints to Image.__init__()

[radarhere]

Alternative to #8275

Once the None return type is added to Image.__init__(), a variety of other changes are needed.

Pillow/src/PIL/Image.py

Lines 535 to 544 in d8447de

	def __init__(self):
	# FIXME: take "new" parameters / other image?
	# FIXME: turn mode and size into delegating properties?
	self.im = None
	self._mode = ""
	self._size = (0, 0)
	self.palette = None
	self.info = {}
	self.readonly = 0
	self._exif = None

[mergify]

⚠️ The sha of the head commit of this PR conflicts with #7461. Mergify cannot evaluate rules on this PR. ⚠️

[akx]

I'm a tiny bit worried about the cost of these assertions within the core library. I think practically no one* runs Python with -O/PYTHONOPTIMIZE that'd wipe these out.

^{*: entirely anecdotal}

[hugovk]

Some discussion on PYTHONOPTIMIZE, showing it does get used:

https://discuss.python.org/t/does-anyone-use-o-or-oo-or-pythonoptimize-1-in-their-deployments/37671

Please could you run some benchmarks to evaluate the cost?

[radarhere]

There's a variety of changes here, but running

python3.9 -m timeit -r 100 -c 'from PIL import Image;Image.new("L", (1, 1)).copy()'

without this change, I get

100000 loops, best of 100: 2.36 usec per loop

With this change, I get

100000 loops, best of 100: 2.37 usec per loop

[hugovk]

I think that's close enough not to worry about. There's some variation as well. Running twice:

without this change, I get:

100000 loops, best of 100: 2.45 usec per loop
100000 loops, best of 100: 2.37 usec per loop

with this change, I get:

100000 loops, best of 100: 2.39 usec per loop
100000 loops, best of 100: 2.41 usec per loop

And similar results across 3.12.

Without:

200000 loops, best of 100: 1.49 usec per loop

With:

200000 loops, best of 100: 1.48 usec per loop

@akx Any further concerns?

[akx]

Now that I think of it, can self.im actually ever practically be None?

Would all of this be simpler if we went for practicality and not purity, and said

self.im: core.ImagingCore = None  # type: ignore[assignment]

or alternatively left self.im unassigned in __init__ and just did

im: core.ImagingCore

as an annotation?

I think #7461 is related here.

[radarhere]

There are other places where it is set to None

Pillow/src/PIL/PngImagePlugin.py

Line 871 in 11b4df3

self.im = None

Pillow/src/PIL/GifImagePlugin.py

Line 158 in 11b4df3

self.im = None

Pillow/src/PIL/GifImagePlugin.py

Line 437 in 11b4df3

self.im = None

The current code does also check that it isn't None

Pillow/src/PIL/Image.py

Line 890 in 11b4df3

if self.im is not None and self.palette and self.palette.dirty:

Pillow/src/PIL/Image.py

Line 907 in 11b4df3

if self.im is not None:

[akx]

If it's only about 5 places, would it make sense to consider whether those places need to do that?

They could delattr(self, "im") and hasattr(self, "im") instead, maybe?

[radarhere]

Now that I think of it, can self.im actually ever practically be None?

I think #7461 is related here.

This isn't just about the edge case of calling Image.Image() directly. It is None before an image is loaded.

>>> from PIL import Image
>>> im = Image.open("Tests/images/hopper.png")
>>> im.im is None
True
>>> im.load()
<PixelAccess object at 0x105d86510>
>>> im.im is None
False

They could delattr(self, "im") and hasattr(self, "im") instead, maybe?

If code simplicity is the concern rather than speed, how about this idea as a slightly smaller change? I've pushed a commit so that using @property, im.im always returns core.ImagingCore. im._im can be used to check for None.

[Yay295]

Couldn't self._im still be None here?

[radarhere]

If it is, the assert will stop the code before the return statement is reached.