On 11 July 2016 at 13:26, Steven D'Aprano <steve at pearwood.info> wrote: > My two core questions are: > > (1) How much extra effort are we going to *mandate* that core devs put > in to hide the differences between C and Python code, for the benefit of > a small minority that will notice them? > > (2) When should that effort be done? Upfront, or when and as problems > are reported or noticed? > > My preference for answers will be, (1) not much, and (2) when problems > are reported. In other words, close to the status quo. I think it's still OK to defer fixing discrepancies between the alternate implementations until people explicitly report a problem, which I guess means the policy update that I'd be looking for is that in cases where the C version currently implements a superset of the Python version's behaviour, the recommended policy be to accept patches to align the two even if: - it makes the Python version more complex and hence harder to read - it makes the Python version slower on CPython (and likely other runtimes without even a method JIT) Replacing a closure with a custom callable (as with the functools.partial patch) is a case where both of those objections legitimately apply, hence making the right thing to do less than obvious given the current wording of PEP 399 - it isn't clear whether those simplicity focused considerations should trump the cross-runtime compatibility ones. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4