First, I appreciate the work you've put into this. But, frankly, I don't know if this is something I could see myself using. The main reason being that it introduces a lot of non-obvious syntax for something as primitive as dict manipulation. I would consider it a burden on whoever is trying to understand my code because this is such a low-level thing to have a customized implementation for. The only trade-off being that I save some time reading KeyError guards or if-statements.

And on the other hand, I'm always unconvinced to utilize a library when examples seem to be constructed strawmen to pit their new implementation against. It's kind of like seeing someone pick a fight with a blind guy; it's obvious you're going to win. The code in your examples is questionably written in my opinion:

for user_name in db:
user_music = None
if user_name in db:
if "interests" in db[user_name]:
if "music" in db[user_name]["interests"]:
user_music = db[user_name]["interests"]["music"]
print(user_music)

out: None
out: ["pop", "alternative"]
Why are we iterating over the keys of db and then checking to see if the keys are in the iterable we're iterating over? That's a given.

Why are we initializing user_music as None? It seems like an attempt to make this code seem even longer and more cumbersome than it really needs to be.

Why are we not utilizing db.items()?

In my opinion, this a more realistic representation of code you'd actually come across in this situation:

for user, user_dict in db.items():
for interest, interest_list in user_dict['interests'].items():
print(interest_list if interest == 'music' else None)

out: None
out: ["pop", "alternative"]
Half the work I do is data analysis and it's also uncommon to encounter data in the form of records with random missing keys (interests I mean). If you find yourself the point where you're handling record data and you don't know if your first nested key is going to exist, let alone the second nested key... It seems like the solution isn't to have more capable dict-handling syntax but to reassess why your data looks like that to begin with and fix that.

I understand that in this context-free example we don't know if interests will be a key for each user. But in reality that would mean an entire column of your records data doesn't exist for an entry. And that's just poor data at that point.

Again, thanks for sharing and I hope this doesn't come off as harsh or discouraging. I just thought I'd share what stopping me and maybe other developers from pip installing your package.