Future support for Python 2 - poll

[nicholascar]

rdflib 5.0.0 has been proposed as the last rdflib release to support Python 2 (and 3.4) due to the maintenance overhead of supporting multiple versions and legacy tie-ins that prevent features of Python 3.5+ being utilised.

We would like to find out if there is strong interest in the rdflib development community in supporting Python 2 (and 3.4) going forward.

Do you agree with dropping support for Python 2 (and 3.4) in future rdflib releases?

Indicate agreement with thumbs up reaction to this, disagreement with thumbs down. If you disagree, please add a comment to this Issue indicating why.

[gromgull]

Get rid of it!

Although obviously, if there ends up being a 5.0.1, or 5.1.0 - they should still keep it.

[nicholascar]

Yes, if we have to make patch/bugfix releases within 5.x, they will keep Py2(+3.4) but this are only releases we are being forced to make to ensure the 5.x series works, not 6.x releases - where we want to be - that will include new features. Would be great to kill Py2(+3.4) to speed up 6.x with Py3.5+ only.

[jwpfox]

👍

…

On 18 Apr 2020, at 15:14, Nicholas Car ***@***.***> wrote: rdflib 5.0.0 <https://github.com/RDFLib/rdflib/releases/tag/5.0.0> has been proposed <https://github.com/RDFLib/rdflib/wiki/2020-04-03-Maintainers-Meeting-Minutes#what-do-we-want-to-tell-people> as the last rdflib release to support Python 2 (and 3.4) due to the maintenance overhead of supporting multiple versions and legacy tie-ins that prevent features of Python 3.5+ being utilised. We would like to find out if there is strong interest in the rdflib development community in supporting Python 2 (and 3.4) going forward. Do you agree with dropping support for Python 2 in future rdflib releases? Indicate agreement with thumbs up reaction to this, disagreement with thumbs down. If you disagree, please add a comment to this Issue indicating why. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1014>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHI5ECMNTH5FYW4FRFTOGLRNEZKJANCNFSM4MLGWNTA>.

[satra]

@nicholascar - just a note that as i redploy rdflib 5.0 through conda-forge, it won't even build a 2.7 version. since 2.x has sunset in the python world.

[koo5]

👍

[OnnoPaap]

Yes, only support for Python 3.x is fine.

[rybesh]

👍

[sa-bpelakh]

👍

[effigies]

Doesn't look like there's anybody speaking up for Python 2, but to flog a dead horse, the maintenance burden of supporting it is only going to get worse as the ecosystem moves on. I maintain a bug-fix-only series of a project to support Python 2.7 through the end of the year. For those releases, I've had to put maximum versions on my dependencies as APIs complete deprecation cycles in Python 3-only versions and start breaking the CI tests otherwise.

I would suggest being pretty drastic and keeping Python 2 support (so your 5.x series) to an absolute minimum of bug fixes, and move master over to Python 3.5+ development.

A couple additional suggestions, from looking at your setup.py:

• You'll probably want to set pyparsing<2.5 for any further Python 2-compatible releases. From the 2.4.1 release notes:

  • NOTE: Deprecated functions and features that will be dropped in pyparsing 2.5.0 (planned next release):
    • support for Python 2 - ongoing users running with Python 2 can continue to use pyparsing 2.4.1

• I would suggest adding the python_requires metadata. That will help pip avoid trying to install Python 3-only releases into Python 2 environments.

[nicholascar]

@effigies thanks for the setup.py tips! The python_requires especially will be useful for pip users.

Yes, keeping 5.x to bug fixes and moving master, the in-preparation 6.0.0 release, to Py3.5+ is definitely the plan.