same comment as on the other PR :-)

Either the comment below is wrong or the code is... if django < 3.0 does not have the class then the imports at the top will already have raised an ImportError.

Also if this method does not serve any other purpose just deal with this in its entirely at the top of the file and at startup time.

@trbs do you mean, have a try-catch block at the top of the file and make an alias for the correct import? Like:

try:
    from django.views.debug import SafeExceptionReporterFilter as settings
except ImportError:
    from django.views.debug import get_safe_settings

I made this function because Django > 3.0 does exist in this class and inside of it, there's the method. For Django < 3.0 does exist only the method

Yes, if the problem is an ImportError then the above should do otherwise you can so something similar with an AttributeError.

But in the latter case at the very least the comment needs to be updated to reflect this.

I think we should keep in this way:

try:
    from django.views.debug import SafeExceptionReporterFilter
except ImportError:
    from django.views.debug import get_safe_settings
...
    @staticmethod
    def safe_settings():
        try:
            return SafeExceptionReporterFilter().get_safe_settings()
        except AttributeError:
            # In django < 3.0 does not have this class
            # We have to make a different import
            return get_safe_settings()

Is safer, we have only one function to return the safe settings and we can update the comment. How'd you think should be the new comment?

This won't work because SafeExceptionReporterFilter will not exist and raise a NameError instead of an AttributeError.

Why if the ImportError gives us all the information not just use that ?

try:
    from django.views.debug import SafeExceptionReporterFilter
except ImportError:
    # Django >= 3.0
    from django.views.debug import get_safe_settings
else:
    def get_safe_settings():
        return SafeExceptionReporterFilter().get_safe_settings()

Having the separate method on the class only makes sense to me if one would expect users to override that.. which I don't think will happen... then something like settings.PRINT_SETTINGS_SAFE_FUNC makes more sense so people have a way to override it... (but we also don't need that right now)

Hmm, I liked your suggestion. I'll add it. Thanks for help me with this!

@trbs Actually, I made a mistake.Django < 3.0 does have the class SafeExceptionReporterFilter, but the method get_safe_settings is outside this class in those versions, only in recent versions the SafeExceptionReporterFilter does have the method get_safe_settings. Look at these links:
https://github.com/django/django/blob/stable/2.2.x/django/views/debug.py#L125
https://github.com/django/django/blob/stable/2.2.x/django/views/debug.py#L72

Even in Django == 3.0
https://github.com/django/django/blob/stable/3.0.x/django/views/debug.py#L72
https://github.com/django/django/blob/stable/3.0.x/django/views/debug.py#L125

Only in Django 3.1 occurs the change
https://github.com/django/django/blob/stable/3.1.x/django/views/debug.py#L108

That's why I used AttributeError

I see... maybe I made a typo when I got the ImportError before...
But we can still use the same style:

try:
    from django.views.debug import SafeExceptionReporterFilter

    def get_safe_settings():
        return SafeExceptionReporterFilter().get_safe_settings()
except AttributeError:
    # Django < 3.1
    from django.views.debug import get_safe_settings

Alternatively we can add this to django_extensions/compat.py and keep this file a little bit cleaner :-)

We should be able to do this cleaner.... it smells like a lot of code duplication to me...

Makes more sense to do something like:

if show_secrets:
    settings_dct = {k: getattr(settings, k) for k in dir(settings) if k.isupper()}
else:
    settings_dct = get_safe_settings()

Sure, I agree!

Can we make the check a little bit more explicit ?

eg use --format=pprint that would allow checking for {'SECRET_KEY': 'dummy'}

$ ./manage.py print_settings --format=pprint SECRET_KEY
{'SECRET_KEY': 'dummy'}

and adding an explicit check for the variant with --show-secrets would be even cooler ;-)

Sure!

use action='store_true' like the --fail option that way we don't need DEFAULT_SECRETS and the cli parser knows how to do the "right-thing"

Right. Thanks for the tip!