Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Consolidate behavior by using filterfalse and always_iterable #3265
As I was searching through the code for a completely different purpose, I stumbled across this pattern, which I've seen many times before:
This common pattern is the reason I created always_iterable, as it allows looping over the items even if there's just one.
Using this technique, along with filterfalse, the code is more concise, less nested, and in my opinion, more directly conveys the intention. One slightly awkward aspect is that the for loop is abruptly terminated if it fails the isclass test, but that was the behavior before as well.
The main reservation I have about this change is that it adds a new dependency, and I'm unsure how important it is to avoid new dependencies. Given that more_itertools implements the recipes from itertools, I find that it tends to have broad appeal and would likely find beneficial use throughout the package (though I haven't surveyed it).
ci is correct - -
since the project has various breaking changes over time, i wonder if its a good idea to make it a dependency tho, i'd like to discuss that a bit since i wonder if users would be afflicted by conflicts
From my perspective, it’s always a risk that a dependency will introduce breaking changes, and rigorous use of Semver to communicate those changes helps mitigate that risk. If one wishes to accept this change but be conservative about possible backward incompatibilities, one may pin an upper bound on 5.0.
I wouldn’t recommend that though. In my experience, the backward incompatible changes have been small and ignorable for my projects. Much of the library is very stable (especially recipes). I’d recommend only blocking new major releases only if there is reason to think that release will affect the usage of that lib in this project.