For the record, here's the benchmark:

importtimeitfromrest_framework.validatorsimportProhibitSurrogateCharactersValidatorvalidator=ProhibitSurrogateCharactersValidator()foriinrange(0,9):length=10**istring="a"*lengthtimer=timeit.Timer("validator(string)",globals=globals())loops,duration=timer.autorange()print(f"{length}\t{duration/loops}")

Okay, so this is a good exercise case...

It's a neat and properly defined little PR that'sclearly an improvement.
We'd need to be wilfully obtuse to say no. Why might we choose to reject even this properly targeted improvement?

Well... because having a steadfast "no" policy is really uncomplicated, and means we don't have continual PR pressure & creep, whichon balance just results in unnecessary busy-work and risk.

I'd suggest we need to be more clear in our language inCONTRIBUTING.md, and just issue a really clear no on essentially all code PRs here. If we're unambiguous about this then we don't have to second guess ourselves.

Suggested language might. be...

REST framework is considered complete. We may accept...

• Pull requests improving the documentation, or adding third party packages to the documentation.
• Pull requests that resolve a CVE'd security issue.
• Pull requests that are strictly required if updated Django versions don't pass some part of our existing test suite.

All other pull requests and issues will be closed.

Yes, there's clearly areas where there's potential performance impacts. There's alsoplenty of areas where there's loosely defined behaviour. However being really clear that this is essentiallya finished project (excepting the points above) would probably be a net benefit.

(The alternative is similar to above, but we allow ourselvessome leeway with a "We'll only consider pull requests that meet an unambiguously high bar of quality". 🤔)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I have rebased this in case you change your mind. If not, just close the PR.

FWIW, thecurrent wording inCONTRIBUTING.md and elsewhere says that

We may accept pull requests that track the continued development of Django versions, but would prefer not to accept new features or code formatting changes.

Since this is neither a new feature nor a code formatting change, it seems like it should be in scope. Of course, it's your project, so I understand if you want to reject it anyway.