The second, longer snippet from the OP article seems to do basically this. To modify it to be exactly like what bullet describes (warning you when in debug or test mode, instead of raising an exception, and have no effect in prod) you can replace line 31 with the logger.error() from line 33, and delete the else-case (lines 32 & 33)

It's not a risk I'm willing to take nor do I believe other general Django engs should take. It's fine if it's a pet project or if you've got deep knowledge of Django's inner workings. This requires understanding the affects of monkey patching core __get__ on DeferredAttribute.

When reading the code vs core Django, it doesn't faithfully reproduce the normal case missing _check_parent_chain[0]. I'm not sure if that code path is supposed to be left out or of it's simply missing? The documentation of the code snippet doesn't explicitly state either.

Code snippets that affect the project as a whole combined with one layer removed is library code. It needs to come with strong specs. The worst case scenario is you get differing behavior in production and development.

I 100% appreciate the spirit of the post, but Monkey Patching core Django files is not to be taken lightly in production code.

[0] https://github.com/django/django/blob/main/django/db/models/...

If I understand it correctly, that's what [django-seal](https://github.com/charettes/django-seal) does.

definitely seems like a good candidate.

There is django-zen-queries[0], mentioned in another comment.

[0] https://github.com/dabapps/django-zen-queries

Not a fan of this one since it only works on templates and requires special code

Never used this, but I see that it provides a context manager/decorator, which you can use to "shield" any code. And also some shortcuts for DjangoREST or something.

Regarding extra code, you can simply replace the Djangos' `render()`, with the one from this lib and you are done. I would have probably made a custom template extension or something to do that for all renders automatically though too.

Yeah I really dislike that. It's putting a code path that will never run in production.

This feels like code that has special switch `if env.is_test` just because you needed that for a spec. It's a really bad practice.

This library sticks that code _everywhere_. The library should be loaded only in local/dev env. Arguably, it shouldn't even be loaded in test. But because of it's style, it needs to be loaded in prod.