django
django copied to clipboard
django
Simplified django.utils.functional.lazy().
I have split the changes into small commits with rationale in the commit message, to make it easier to review and drop undesirable changes if needed. Should probably be squashed before merging.
~~The last commit "Fixed wrong caching of class preparation." fixes a performance issue that affected us in production. It can be applied separately.~~ Moved to a separate PR: #11399.
The CI failure is unrelated: hudson.plugins.git.GitException: Failed to fetch from git://github.com/django/django.git.
Based on my comments, are we sure that there isn't some untested case that has changed?
In your example lazy(lambda: 1, str)(), the function returns an int but the specified resultclass is str. This I believe is already "illegal" and breaks the contract of lazy and will cause super-confusing issues to anyone who does this by mistake. So I think it's OK.
In your example
lazy(lambda: 1, str)(), the function returns anintbut the specified resultclass isstr. This I believe is already "illegal" and breaks the contract oflazyand will cause super-confusing issues to anyone who does this by mistake. So I think it's OK.
Yeah, that was a sloppy example, but it "worked" before. I fear that we are now claiming str and bytes to be equivalent which definitely feels like a regression.
It seems ill-defined what makes sense here. The (now-removed) code that asserts that bytes and str are incompatible. The undocumented invalid combinations, e.g. str and int. The apparently valid str, tuple and list for get_format_lazy().
Maybe all the complexity is just a hang over from the old Python 2 days of str vs unicode and not all that has been removed.
Yeah, that was a sloppy example, but it "worked" before.
I don't think bug-compatibility should be kept here, especially since making this mistake is very visible so it's unlikely that some code has this bug and is working correctly.
I fear that we are now claiming str and bytes to be equivalent which definitely feels like a regression.
I don't quite follow, can you clarify what you mean by equivalent?
Maybe all the complexity is just a hang over from the old Python 2 days of str vs unicode and not all that has been removed.
That's my understanding, that the _delegate_bytes and _delegate_str is only Python2 compat legacy. Why should str and bytes be special otherwise?
I couldn't resist adding another commit, "Changed proxy to prepare eagerly." (the commit message explains).
Rebased. The two conflicts were with 577f2338f16bea055abc49c5a43fa3ecb05dffc8 and 775b796d8d13841059850d73986d5dcc2e593077 (cc @hramezani) which were not semantic conflicts, except for the test which is now passing because having both str and bytes in resultclasses is now allowed.
Merged the first two commits in 0a132de7ebe1e2679ff7d7f6b6e1ad920828dd90 and 066aabcb77579cf8d549119c860d11cd15e3eef1.
@bluetech Hi! I'm doing some PR cleanup, would you have time to update this PR with the latest main? Thank you!
@bluetech Let me know if you don't have time to keep working on this, I'm eager to move it forward.
I might be able to pick this up. Have a few ideas for further improvements.
@felixxm @ngnpope Would be happy if you pick this up. It will take me some effort to page these changes in. But I can do the rebase if that would help - let me know.