Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

ProbstDJakob
Copy link
Contributor

@ProbstDJakob ProbstDJakob commented Feb 4, 2021

Important: this PR only exists to split up the PR #208

  • make _LDAPConfig.logger and NestedMemberDNGroupType.find_groups_with_any_member protected
  • directly convert the group info into a dict in NestedMemberDNGroupType.user_groups
  • check _group_type and _group_search against their corresponding type instead of None in _LDAPUserGroups._init_group_settings()
  • use the settings object instead of the django settings to retrieve the global options in LDAPBackend.ldap()

@francoisfreitag
Copy link
Member

Please split this PR into independent PRs, so that each improvement can be reviewed, discussed and potentially integrated separately. For example, “remove defaults dict in LDAPSettings” is not related to “restrict django22 dependency in testenv of the tox.ini to 2.2.* not just to a compatible version”.


What is the benefit of “restrict django22 dependency in testenv of the tox.ini to 2.2.* not just to a compatible version”?
Based on https://www.python.org/dev/peps/pep-0440/#compatible-release, ~=2.2.0 means >=2.2.0, == 2.2.*, which results in the latest version of Django 2.2 being selected.

@ProbstDJakob
Copy link
Contributor Author

What is the benefit of “restrict django22 dependency in testenv of the tox.ini to 2.2.* not just to a compatible version”?
Based on https://www.python.org/dev/peps/pep-0440/#compatible-release, ~=2.2.0 means >=2.2.0, == 2.2.*, which results in the latest version of Django 2.2 being selected.

I had the behaviour of ~2.2 in mind, which would possible resolve to the wrong version, but since I was wrong, this change has no effect except for the uniformity. But with this new information, I would prefer to use the Compatible Release Syntax for all dependencies.

@francoisfreitag
Copy link
Member

That works for me, the compatible release syntax is also shorter 👍.

Jakob Probst added 2 commits February 6, 2021 04:30
- add python 3.6+ type hints
- replace applying defaults dict in LDAPSettings with actual variables, allowing type hints, checking if variable exists (e.g. IDE), and preventing supplied defaults dict (LDAPSettings.__init__) to inject undesired variables
- add AbstractLDAPSearch as abstract base class
- fix (by removing) result of search_s not being checked if None in LDAPSearch.execute
- add conversion to string in AbstractLDAPSearch._escape_filterargs
- rename AbstractLDAPSearch._begin(...) to AbstractLDAPSearch._search(...) and AbstractLDAPSearch._results(...) to AbstractLDAPSearch._result(...)
- add AbstractLDAPSearch._abandon(...)
- LDAPSearch._search(...) saves the msgid inside the object instead of returning it
- make LDAPGroupType abstract
- MemberDNGroupType.is_member(...) now returns bool instead of Union[bool, int]
- remove kwargs from LDAPGroupQuery.__init__
- update test mocks corresponding to the AbstractLDAPSearch changes
- make _LDAPConfig.logger and NestedMemberDNGroupType.find_groups_with_any_member protected
- directly convert the group info into a dict in NestedMemberDNGroupType.user_groups
- check _group_type and _group_search against their corresponding type instead of None in _LDAPUserGroups._init_group_settings()
- use the settings object instead of the django settings to retrieve the global options in LDAPBackend.ldap()
@ProbstDJakob
Copy link
Contributor Author

The PR has been split into (#231,) #232, #233, #234, #235, #236, #237, and #238.

@francoisfreitag
Copy link
Member

Thanks for splitting the PR further. Commit “chore(type_hints): add type hints and minor changes” is included with all the PRs, but I don’t think it should be, it is not necessary for each PR.

For each PR, please justify why the suggested change is an improvement for the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants