Support 3.9

[mzpqnxow]

Much of this came from the conda-forge blist-feedstock patches once I stumbled across them, thanks to @h-vetinari for that

This addresses a handful of open issues, some of which have fixes in other trees and/or have open PRs here

Overlapping PRs: #92 , #91, #85 (I think #85 may break 2.x but I didn't look too thoroughly) Issues that it should fix: #81 , #79, #90,

Because there are so many overlapping PRs I don't expect you to sift through this- you may just want to close it. I'm going to keep my fork+branch and use that for now, I needed something for ppc64le system with Python3.9.5 which is how I ended up going down this road. I figured I might as well send what I have upstream (even if it's an amalgamation of things that already have PRs)

The summary:

• Fix import breakage on 3.9 as well as soft-fails (DeprecationWarning) on >3, <3.9 - applies to some tests, the package init and the _sortedlist module
• Changes required for 3.9 due to PEP-0620 changes; taken from https://github.com/conda-forge/blist-feedstock
• Changes for PEP-479 from conda-forge blist-feedstock patches
• Remove unnecessary preprocessor macros, from conda-forge blist-feedstock patches

Thanks for this project, it's very nice having something as a drop-in replacement for list for cases where numpy arrays don't quite make sense

[h-vetinari]

Thanks for tagging me here. Unfortunately I believe this repo is completely dead - I've tried to keep up with making it compatible for conda-forge, but patching in new python version support is kind of a gray area I'd normally try to avoid in packaging. The few projects I knew that depended on it have dropped this dependency due to the lack of updates, so it all looks very moribund to me.

As such, I don't care too much what you do here, but I'll just note that I'd have considered it "cleaner" not to rebrand my patches (even though you do reference them), but just take them as-is and then layer your changes on top.

[mzpqnxow]

Thanks for tagging me here. Unfortunately I believe this repo is completely dead - I've tried to keep up with making it compatible for conda-forge, but patching in new python version support is kind of a gray area I'd normally try to avoid in packaging. The few projects I knew that depended on it have dropped this dependency due to the lack of updates, so it all looks very moribund to me.

Understood- I entered an issue about a week ago here to confirm the project was unmaintained but I was surprised to see his quick reply confirming that the project was still maintained. This is why I decided to send changes upstream. It's evident of course that 3.9 is not supported- which is understandable, since relatively few projects are using 3.9 and I'm sure development for this project is not funded

As such, I don't care too much what you do here, but I'll just note that I'd have considered it "cleaner" not to rebrand my patches (even though you do reference them), but just take them as-is and then layer your changes on top.

Also, understood and agree with you completely. Generally, I wouldn't use the haphazard process I used (applying the patches piecemeal, mixed with some of my own changes) but the way this went was as follows- I know you probably don't care to know all of this, but in case you are curious how this happened-

• The blist collections import issues were the first breaking issue when I ported my app to 3.9; these were trivial to fix, so I did that myself, naively thinking that would be the only change required
  • I did search open open Issues and PRs in this project and a few PRs but none seemed to fix the immediate issue I was having (the imports issue) - some of the PRs broke 2.x compatibility so I decided I would patch it myself, for better or for worse
  • I failed to search GH to see if there was already a fork with a 3.9 supported branch (d'oh!)
• After fixing the imports issue, I then encountered the issue with the GC symbol missing. I determined to be a symptom of PEP-620 and that's when I became aware of your fork / patches
• I applied your patch for PEP-620, built the module and tested it in my project and saw no regressions, and thought "all done"
• I then realized that would be pretty careless and probably would lead to trouble, so I ran the testsuite like a sane person would. That's when I realized your PEP-479 was probably a good idea :)
• At that point, I figured I ought to take all of the patches (which I should have done from the start)

I realize my folly on this is not really any skin off your back but you took the time to provide this guidance and I'm appreciative of that. Regardless of your exact intention (which was clearly meant in general to be constructive) it helped me specifically realize that the entire process was sloppy. Lesson learned

I'm going to close this PR and see if I can just point my constraints at your blist branch for now. As long as it addresses the collections.abc import issues along with the others (I'm sure it does, if you have a user community on 3.9) then it should be better than maintaining my own fork + branch and will reduce confusion

Finally- I'll address a comment to @DanielStutzbach - do you have any interest in bringing the enhancements in blist-feedstock upstream? If you or @h-vetinari don't think it's constructive then that's no problem, I just thought it would be helpful for any users installing blist via pip, as they will run into the same situation I did when they get to 3.9

If there is any interest in doing this, I'm happy to prepare the PR (in a more generally accepted and thoughtful way, this time)

I'm not volunteering anyone else to do any work

Thanks for your input. Please do not apply this PR- I will leave it open for the moment to see what @DanielStutzbach would like to do

[h-vetinari]

Happy to hear that this project is apparently not dead - though I'll reserve judgement until some PRs actually get merged 🙃

Thanks for taking the time to dispel any doubts (though I didn't have any impression that you're being disingenuous).

If you want to start off of my patches, you could rebase your changes on top of them (I can also push my branch with them to github, if that makes things easier). GH also allows force-pushing on PRs, so you don't necessarily need to open a new one.

In any case, I'd be happy to see the changes merged (incl. the abc-stuff).

[mzpqnxow]

@DanielStutzbach any thoughts on whether >= 3.9 will be supported in your branch or (ideally) a packaged release?

Clearly blist is being used- and it seems that I'm not the only one using it- might you consider taking this PR (or perhaps the patches from @h-vetinari ), merging and releasing a new package at some point?

If not no worries, but I will close this issues out

Thanks!