Should PyShp drop support for Python 2, and Pythons earlier than 3.8?

[JamesParrott]

Following issue #276, PyShp users and contributors, please let us know below how dropping support for older Pythons would impact you, especially if there would be negative impacts.

Note, there is no proposal to yank PyShp versions that support older Pythons. So this will not break anything that installs PyShp from PyPi using the pip for that version of Python. This would effectively be a feature freeze, not a mandatory upgrade for users. Unsupported does not imply unavailable.

Pros:

• Best practise for security. These Python versions are (or for 3.8 will soon be) no longer supported by the PSF. PyShp does process raw binary files, that could be maliciously constructed to contain anything.
• Not a breaking change. Version pinning is not even required from users, if PyShp is installed with a dropped Python's pip.
• Encourage more contributors, ensuring PyShp thrives as a healthy open source project, for the next 10 years. New contributors may prefer to write Python code using more recent, modern features, e.g. f-strings.
• Eliminates a whole class of possible future bugs, and reduces the attack surface, improving security.
• Facilitates a general tidy up of the code base, increasing readability.
• Allows static type hints to be added.
• Manage user expectations. I.e. in future, we contributors -may- still choose to fix Python 2 bugs. However, we contributors should not be expected to fix Python 2 bugs. The advice will be to upgrade Python and PyShp versions.
• Reduces technical debt (allows deletion of the code that only runs in Python 2).

Cons:

• It ain't broke, so don't fix it.
• PyShp is one of the only libraries available that supports users running older Pythons - it's a USP!
• Creates work.
• Few users process arbitrary shapefiles from the wild. If they are running PyShp and Python 2 on their web server, they probably have much more important things they should worry about.

Proposed roadmap:

0. Announce proposal. Gather feedback. Participate in this very discussion.
1. October 2024, after Python 3.8 EOL. Release PyShp 2.4 with notice (deprecation warning if possible) that the upcoming 3.x releases will drop support for Python 2 and any Python below 3.8 (and changes for devs, e.g. Code formatter).
2. On the main branch, remove support for pythons 2, 3.5, 3.6, 3.7 and 3.8.
3. Release Pyshp 3.0 (support for Pythons >= 3.9 only).
4. Allow X months for user feedback.
5. Release 2.5, advertising PyShp 3, and announcing end of support for PyShp 2
6. 2025-10 drop support for python 3.9
7. 2026-10 drop support for python 3.10
8. Thereafter, follow https://devguide.python.org/versions/

[JamesParrott]

I've reached out to all the other contributors, but couldn't otherwise contact you guys: @lgolston @lemonez @bva-bme @eumiro @midichef

[JamesParrott]

Also: @cwalv @atlefren

[sebastic]

The proposed changes don't affect the Debian package.

[schwehr]

My main take is that dropping support for older versions reduces the maintenance burden for the main branch, which anyone needing support for older versions can do that in a branch.

Also, the addition of type annotations will make the library easier to use for many and possible catch some bugs in the process.

[mwtoews]

Generally, I don't think users of older/unsupported Python versions should expect maintenance from most packages. Previously published versions of packages are always available, so nothing is being taken away.

[dbotwinick]

Adding a comment since I got a message about this today. All fine with me (as a user who has dependencies on pyshp). Any legacy stuff I have out there should still work with the older versions... and anything reasonably current is on at least python 3.10 right now (generally 3.11). I don't think staying in line with the Python release cycle is unreasonable given the 5yr life... and type hints, etc. are nice.

[cleder]

+1 the next version of fastkml will most likely also drop support for python versions < 3.9

[bosth]

I was also contacted since plpygis uses pyshp (only for testing though), and I have no concerns about losing support for 3.8.

[JamesParrott]

Thanks for the responses everyone. It's much appreciated.

I messaged the authors and maintainers of about 138 dependencies in total (including you three, Drew, Christian, and Benjamin). I will not be sending out any more messages, so (not that anyone has) there's no need to unsubscribe etc.

I wrote some code that tried to drop projects from the contact, that I could tell via the requires_python or Trove classifiers, had already themselves dropped Pythons <= 3.8. However I don't claim this code is foolproof, so my apologies to those who were emailed unnecessarily - you're already way ahead of us.

[mshumko]

Hi @JamesParrott, I think that you're safe to drop Python <= 3.8. Since many of us use numpy, numpy==1.24.0, released on Dec 18, 2022, was the last version that supported python 3.8...