Remove the _delegate_text attribute, which is being removed in django 5.0 (#9274)

[TGoddessana]

… django 5.0

Note: Before submitting this pull request, please review our contributing guidelines.

Description

This pull request resolves #9274

1. the implementation of force_str in django 3 and django 5 versions doesn't seem to differ much except for a few code styles (https://www.diffchecker.com/kGpPbE3K/)
   Therefore, I don't think we need to add logic in our code to look at the django version.

2. the removed _delegate_text being False means "don't expect that object to be a string", so I think adding strings_only like the code in the original issue is sufficient.

P.S.: If @jayden-arrai can send us a better PR, I'll close this one. I hope this doesn't offend the original issue raiser..

[jayden-arrai]

Let me check if force_str has the strings_only arg in django older than 5. If it does, then this should be sufficient.

[jayden-arrai]

So, I took a look at the django commit history. In django 2.2 this function used to be called force_text, and that version of the function already had strings_only:
django/django@3bb6a43

So django 3+ would be good with this change, and it looks like django 2 is no longer supported in django rest framework.

[TGoddessana]

yes it is. The right and left parts of this link refer to django 3.2 and django 5.0, respectively, and I don't think there's much difference.

[tomchristie]

Okay, I've taken a look and approved because that's what I'm used to doing, tho isn't necessarily the best reflex here.
I think we ought to be expanding invites to @encode/django-rest-framework here, and then allowing y'all to approve & merge... (?)

[TGoddessana]

I was wondering, how do you get the maintenance credentials (?) to get invited and sign off on certain pull requests? I'm guessing it should probably be people with a thorough understanding of the entire codebase and a proper roadmap, but I'm wondering how we go about picking people who will make sure the project doesn't go off the rails.

[auvipy]

I was wondering, how do you get the maintenance credentials (?) to get invited and sign off on certain pull requests? I'm guessing it should probably be people with a thorough understanding of the entire codebase and a proper roadmap, but I'm wondering how we go about picking people who will make sure the project doesn't go off the rails.

I agree with your view. only people with good enough contributions history.

[tomchristie]

The Trio team use this...

After your first PR is merged, you should receive a Github invitation to join the python-trio organization.

Perhaps we could write this (or something similar) into our contribution docs?

(Alternately, Jazzband has an automated process...)

login with GitHub and then follow the instructions on your account dashboard.

[TGoddessana]

Would it be a good idea to write a similar article after this section?

If we know the details of how to get invited as a contributor, it would be great to write it up.

Jazzband is automating that process based on this website, so I guess it's a matter of how we want to structure our policies.

[tomchristie]

Would it be a good idea to write a similar article after this section?

That seems sensible yep - what policy should we start with?
Invite after first pull request, or something else?

[TGoddessana]

Do you have any thoughts on what permissions an invitee might have on our codebase?

I think it's appropriate for the invitee to have the following two of the permissions mentioned in trio.

1. label incoming issues in the project, close them, etc.
2. merge code where a core contributor has approved the change.
3. If it's more appropriate for a discussion than an issue, turn it into a discussion.

I think they should be able to do this. There are still often PRs in this repository that add functionality that can be solved by third-party packages.
The inviter should be someone who can judge if such a feature is reasonable and say "no".

I still think it's okay to have a manual review after the first PR submission and then send out invites, as long as it's done by a human who is checking the PR and sending out invites.