drop old/dead pythons?

[ThomasWaldmann]

considering the "start backporting from scratch to get the latest features from 3.7/3.8 stdlib scandir" suggested in #108:

i could have a look, but when looking at the current setup.py it seems that py26, py27 and py34 are currently supported by scandir pypi edition - this is definitely something i would not like to work on, considering theses are all dead now or in the near future.

supporting py35, py36[, py37] with the latest stuff from py37 [or py38] stdlib seems way easier and less error prone also.

the question is just whether this is doable / wanted within benhoyt/scandir and would just result in a new major release (and all users wanting the old stuff would just require a lower version) or whether a new project is more appropriate.

[ThomasWaldmann]

Dropping py34 or not could be done depending on the estimated effort to support it.

If it's easy enough we could also still support it for a while (but that would need some pinning for pip and maybe pytest, which both will drop support for py34 soon).

[benhoyt]

Thanks for that! I'd be happy dropping 2.6. However, I think we definitely need to keep 2.7, as one of the main reasons for this library is to get scandir functionality on 2.7 (if you want it on Python 3 you can just use Python 3.5+). I do realize that Python 2.7 support is probably the hardest part of this, as some of the C API changed between 2.x and 3.x.

Similarly, I'd love to keep Python 3.4, as scandir was introduced in Python 3.5 so folks using Python 3.5+ don't really need it (apart from the new "with" statement and other newer features). In any case, I think keeping 3.4 support won't be too hard.

Thoughts?

[ThomasWaldmann]

For me the reason for using an uptodate pypi scandir lib would be only to get dir_fd support (needed for less race conditions, maybe also a little bit better performance).

I need it for borgbackup master branch and that does not support py < 3.5 (nor py 2.x) anyway.

So you see, at least I want it to be able to support py 3.5 and 3.6. :)

[ThomasWaldmann]

One approach to do it here could work like this:

• create a new scandir3 branch and work on a new implementation, working backwards from 3.8 (or 3.7), at first supporting 3.6, then 3.5 (== what i would work on), then 3.4 (if somebody wants to do it), then 2.7 (if somebody wants to do it).
• as soon as scandir3 is ready for release, merge it into master and release scandir 3.0 from it.
• create a new scandir2-maint branch from the last old codebase changeset (supporting py2.x, py34, ...). the releases from that branch would be all with versions < 3.0.

The idea with the new "3" major release is to indicate an incompatible change (== not supporting some of previously supported py version, at least not initially) and also indicating that it is py3 only (at least initially, maybe forever if noone steps up doing the py27 changes).

[ThomasWaldmann]

Alternatively, it could be just a separate "scandir3" project.

[benhoyt]

@ThomasWaldmann Doing the work on a new scandir3 branch sounds good. I think we should aim to support 2.7 rather than having a separate scandir3 project. Once we get it going on 3.4+ it shouldn't be too hard to get it going on 2.7, and I can help with that part if needed.

[ThomasWaldmann]

current state in master: supporting 2.7, 3.4/5/6/7, dropped older stuff.

[ThomasWaldmann]

Guess I can't/won't work on the "scandir renovation" branch / PR.

So whoever wants to take this, feel free to do so!

[benhoyt]

Going to close. 2.6 is no longer supported, though it does still support 3.4 (as os.scandir wasn't in that version of Python 3).