dj-tracker VS python-uncompyle6

I'd recommend dj-tracker. It can show you exactly which field your related queries come from and you'll easily be able to know when your N+1 problem is solved or not using the dashboard. See the Detect and resolve related queries page on the docs. (It comes with very little overhead compared to silk or debug-toolbar and it persists all the data in a database so you don't lose when you quit the server).

You could try dj-tracker. It'll help you detect N+1 or any related queries but also apply the deferring optimisation suggested by eysidi.

That was the little story for dj-tracker and here is what it can do in summary: - Keep track of all fields accessed (allowing to use only or defer when some fields aren't used - Keep track of all attributes accessed (it can then give you a hint to use .values or .values_list) - Show how effective a queryset's cache is (and provide hints on using the .iterator optimisation) - Show all related queries in the same section and where they come from (making it super easy to detect N+1 queries) - Detailed traceback, SQL and template information for each query - Everything is persisted in a database so you can see how your application performs over time

For these reasons and many others (we lose the data as soon as we quit the session, it only keeps track of queries inside a request/response cycle i.e not in a background job for example...), I started building an app (dj-tracker) that can give you various insights into your queries but also hints on how to optimize them.

Hmm, interesting. There is a Github action that builds wheels and uploads them to Pypi. That's why I didn't specify Cython in the project's dependencies. I guess I'll need to look at it more in-depth. I'll also update the documentation re urls.

Q: What is RAPID_API_KEY = os.environ.get('RAPID_API_KEY')? A: You should store configuration in environment variables; never in code. See 12 factors app. Python .pyc files can easily be "decompiled" to .py and reveal all secrets in code.

I was able to figure out that this is a python program which was compiled to an .exe. Using uncompyle6 and pyc2bytecode, I was able to decompile the .exe into the python bytecode...but I'm no expert at reading python bytecode. If you want to do this yourself, note that you will need to use the same version of python as the version used to make the exe (python 3.9). I did easily by changing the python_version in my Pipfile to 3.9 and using pipenv shell.

It's a Pyinstaller binary.(I have used it once before, so I just knew it by checking the file.) Use https://github.com/extremecoders-re/pyinstxtractor to extract its source code archive in binary (by just running python pyinstxtractor.py ./backdoor or something), now many .pyc files are extracted. Find src.pyc and it's malformed as Python3.9, so https://github.com/rocky/python-uncompyle6/ denies to decompile. But challenge information says it's Python3.8, so I write helloworld python script and execute it with Python3.8. It yields Python3.8 .pyc file. Analyze it and find signature is \x55. Change src.pyc's signature from \x61 to \x55 and decompile by running uncompyle6 backdoor-src.38.pyc > backdoor-src.py

If not, you’ll either need to install and use 3.8 to run the program, or you’ll need to help the author continue support beyond 3.8.