The static files panel shouldn't choke on unexpected data types

[matthiask]

Description

Using Path() instances in static() is unexpected but we shouldn't crash.

While debugging I found that our DebugStaticFilesStorage.url instantiates a StaticFile which in turn calls DebugStaticFilesStorage.url again, so rendering self.panel.content in my test wouldn't end ever. What was tricky about it is that I didn't get an infinite recursion error because we're using a signal. (To be clear: I'm not sure this is what happens, I only think it is.)

I'm confused why this wouldn't have appeared earlier, but I'm happy with the fix.

Fixes #2002

Checklist:

• I have added the relevant tests for this change.
• I have added an item to the Pending section of docs/changes.rst.

[tim-schilling]

The code makes sense. I don't have ideas on why this would break either but I'm happy to see a problem solved

[salty-ivy]

What was tricky about it is that I didn't get an infinite recursion error because we're using a signal. (To be clear: I'm not sure this is what happens, I only think it is.)

If that were to be the case, wouldn't we will have numerous signals for a single request, if call staticfile.url()

[salty-ivy]

What was tricky about it is that I didn't get an infinite recursion error because we're using a signal.

Just checked.

we can still hit the maximum recursion depth if we make a call to StaticFile(path).url() within DebugStaticFilesStorage.url()

I think that concludes that signal is not the reason and staticfile.url() is not being called within DebugStaticFilesStorage.url() in any typical case.