Re: PASSWORD_HASHERS Check

For context, Francisco proposed this at https://code.djangoproject.com/ticket/33793 which was marked wontfix by Mariusz with the comment: > Django keeps "weak" password hashers for support with legacy systems and ​speeding up the tests

PASSWORD_HASHERS Check

I think it would be a good idea to add a check for insecure hashers on PASSWORD_HASHERS[0], I know the insecure ones are not enabled by default, but I think it would be useful to warn users that have enabled them that it's a bad idea. They could have enabled them on production while thinking th

Django 4.1 beta 1 released

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2022/jun/21/django-41-beta-1-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

I don't like get() and catching exceptions. What I usually do is something like this: foo_list = Foo.objects.filter(x=x) if (len(foo_list) == 1): foo = foo_list[0] And if I need else, I can assign None or whatever. The advantage in this way is that you don't get an exc

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

A common idiom is also ``` try: foo = Foo.objects.get(x="foo") except Foo.DoesNotExist: foo = None ``` which is pretty pythonic IMO, but I wouldn't be opposed to a keyword-only argument on `get` that returns `None` if not found ``` foo = Foo.objects.get(x="foo", strict=False) # or foo =