I have made the decision being well aware of @rhettinger’s opposition the last time this was proposed.
This is exactly what this implements.
I addressed a certain part of opposition from back then and I think that this proposal adds new information too:
- My research suggests that there is a considerable amount of repetition implementing such functionality (this has not been emphasised last time). At the same time, none of them are implemented efficiently.
- I have a working code with benchmarks and a case for performance, which wasn’t the focus last time. Performance of such python implementation compared to C extension is more than 10x times higher. This also provides ability to efficiently make use of performant functions in standard library at a fraction of cost. Together these can be a powerful toolkit for cases where performance is crucial.
- I have found that implementation does seem much more simple and robust than I initially though. I would dare to guess that implementation and maintenance cost might have been overestimated at the time.
- Finally, this suggestion came from a certain endeavour to improve performance of particular problem so I hope this can be seen as positive contributing factor to the case.
So I would be happy to receive a sincere reconsideration as I currently genuinely think this could be a valuable addition.