Refactor EpsImagePlugin and deprecate PSFile#6879
Refactor EpsImagePlugin and deprecate PSFile#6879hugovk merged 18 commits intopython-pillow:mainfrom
Conversation
Merge the PSFile class into the EpsImageFile class to hopefully improve performance. Also added a check for the required "%!PS-Adobe" and "%%BoundingBox" header comments.
1cbb456 to
aab8289
Compare
aab8289 to
0334e68
Compare
class PSFile:
"""
Wrapper for bytesio object that treats either CR or LF as end of line.
+ This class is no longer used internally, but kept for backwards-compatibility.
"""If we're no longer using it internally, do we need to keep it around in the API? Can it be deprecated? Is there a replacement? |
|
" I don't know how to add a deprecation warning though; I haven't done that before. |
|
Yup. To deprecate something:
Searching the top 5k projects on PyPI shows no real use of $ python3 ~/github/misc/cpython/search_pypi_top.py . "\bPSFile\b" -q
./pyre-check-0.9.16.tar.gz: pyre-check-0.9.16/typeshed/stubs/Pillow/PIL/EpsImagePlugin.pyi: class PSFile:
./Pillow-9.3.0.tar.gz: Pillow-9.3.0/Tests/test_file_eps.py: t = EpsImagePlugin.PSFile(f)
./Pillow-9.3.0.tar.gz: Pillow-9.3.0/Tests/test_file_eps.py: t = EpsImagePlugin.PSFile(r)
./Pillow-9.3.0.tar.gz: Pillow-9.3.0/src/PIL/EpsImagePlugin.py: class PSFile:
./Pillow-9.3.0.tar.gz: Pillow-9.3.0/src/PIL/EpsImagePlugin.py: fp = PSFile(self.fp)
./pytype-2022.10.26.tar.gz: pytype-2022.10.26/pytype/typeshed/stubs/Pillow/PIL/EpsImagePlugin.pyi: class PSFile:
./types-Pillow-9.3.0.0.tar.gz: types-Pillow-9.3.0.0/PIL-stubs/EpsImagePlugin.pyi: class PSFile:
Time: 0:00:23.017025
Found 7 matching lines in 4 projectsAnd I didn't spot any relevant use in the 940 GitHub results. But before we go ahead, @radarhere what are your thoughts? |
|
I don't mind deprecating You've also made various other changes here, such as making use of |
|
This plugin reads lines byte-by-byte until it reaches the end of the line (or 255 bytes). Pillow/src/PIL/EpsImagePlugin.py Lines 175 to 191 in 0ad275f My version instead reads the bytes into a fixed bytearray. This can be done because we know we can't have a valid line longer than 255 bytes, so we can allocate the space for that at the start and just reuse it for each line. A memoryview is just a wrapper around this byte array that lets us use subsections of it without having to create a copy of that subsection.
|
0833edb to
bd0fac8
Compare
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
and remove empty comment lines
|
|
||
| if not box: | ||
| if not self._size: | ||
| self._size = 1, 1 # errors if this isn't set. why (1,1)? |
There was a problem hiding this comment.
Could you tell me what the "errors" are? I don't see any coming from our test suite - https://github.com/radarhere/Pillow/actions/runs/4582259664
There was a problem hiding this comment.
I checked out the first commit in this branch, removed that line, and ran the tests, and there weren't any errors. So I'm not sure what error I had seen back then.
Merge the PSFile class into the EpsImageFile class to hopefully improve performance.
Also added a check for the required "%!PS-Adobe" and "%%BoundingBox" header comments.
This hopefully helps with #6877.