Help Decide the Future of rows - Which Python Version Are You Using?

[turicas]

Hello rows users and contributors!

After a long hiatus without new releases (despite the continuous development in the develop branch), I'm finally actively working on the next version: 0.5.0. This will be the last release to support some older Python versions (such as 2.7 and 3.5). Maintaining compatibility with outdated Python versions requires extra effort, but before dropping support entirely, I plan to release 0.5.0 with deprecation warnings (only bug fixes will be implemented for this minor release, no new features will be added). Then, in 0.6.0, support for these older Python versions will be officially dropped.

I've been working on #372 to ensure rows runs on all currently supported Python versions and fix all the existing tests/issues before this new release. This change will help simplify the codebase and accelerate future improvements to the library. However, I want to make an informed decision based on real-world usage.

According to PyPI download stats, some users are still installing rows from Python 2.7 and 3.5:

The decision will also consider:

• Python EOL (End of Life) dates
• Debian and Ubuntu EOL dates and their respective Python versions

[douglassgomes]

Por aqui 3.13.2, no Debian Trixie. Mas ainda não usei rows.

[jsbueno]

I think it makes sense to go with the Python's that are not EOLed -
I don't remember if any meaningful syntax/features where added with 3.9 -
In 3.8 we got the Walrus operator, which can prettify (but also uglify :-) ) code
in serveral places.

With 3.10, IIRC we have class unions with "|" which I use a lot in new code
(even in untyped code, with "isinstance" ). 3.11 has unrestricted f-strings, which
rows could make use of in new code -

And even though LtS S.O. versions might feature relatively old Python as the
system Python, any Python code running on these will be likely using venvs with
newer versions (or could). It was already the best practice, nowadays, with uv it is almost seamless.

So, I go with shave-off EOLed Python - currently, the oldest supported is 3.9

As for those Python 2 users - they can keep the existing version - it is well past time to drop
all the wheels needed to keep compatibility. (It has been a fun decade writing code that
would run on both Python 2 and 3, but that is gone).

[a-detiste]

rows can stay heavily patched in the next release ... I don't mind

[a-detiste]

Sometime upstreams do mind because the Debian package does not looks like what they published at all...

[turicas]

@jsbueno creating another package will cause confusion. I prefer to do this way: for the last time, I maintain old Python versions in this next release. Then, I completely remove the if PY2s and everyone will be happy. I'm almost there - the most difficult things about this next release are not related to Python 2 at all (but to make all the tests pass and fix many things that weren't fixed for a long time).

@a-detiste I prefer to apply all the patches (or do equivalent fixes) so you as a package maintainer don't have too much work (sorry for this) and users won't see any difference between versions installed via pip or apt (having two "versions" could make bugs more difficult to track/solve also).

[a-detiste]

Needing unicodecsv only on Python2 would be nice.

One can look inside unicodecsv to see how it's implemented: there's a py2.py a py3.py and a init.py that import the right one.

I guess you want to use the Py2 class and have clean codepath on Py3 not relying on unicodecsv

https://github.com/jdunck/python-unicodecsv/blob/master/unicodecsv%2F__init__.py

[turicas]

Needing unicodecsv only on Python2 would be nice.

I'm trying to get rid of it even on Python2! Still need to add some tests, but the current CSV tests are passing for all Python versions (2.7, 3.5-3.13) in fix/python-versions.