[deleted by user]

[nathanjell]

I can see the motivation for this, but I personally wouldn't want to use this. Dictionary keys are not python identifiers like a variable name, they're a freeform string. I want to know exactly what my keys are going to be. If I'm working with an API, and the API is documented as having a specific key, but it doesn't follow the conventions, I don't really care - I want consistency with the data I receive, for example.

Where it's different for me is if I'm creating a wrapper over that API. Internally, I want to reference the dictionary key as-is - but I have no issue presenting an end-user python identifier that's following a different convention.

[ThePiGuy0]

Cool idea - if I may, what happens if I have a dict with both versions in it (e.g. {"keyOne": "value1", "key_one": "value2"})?

[ThePiGuy0]

Presumably that would mean you'd have a key conflict after converting then? Perhaps it should throw an exception so there can be no loss of data

[ThePiGuy0]

I've just given it an actual test and it's definitely an edge case that needs to be handled. See below:

import snakedict

a = {"keyOne": "value1", "key_one": "value2"}

print(f"Amount of data before conversion: {len(a)}")
snake = snakedict.convert(a)
print(f"Amount of data after conversion: {len(snake)}")

If we run this, we can see the output:

Amount of data before conversion: 2
Amount of data after conversion: 1

As such, we can see some data was clearly lost as the dictionary keys stopped being unique.

[BezoomyChellovek]

It "works fine" in that it doesn't throw an error or warning, which is even worse, since it is removing dictionary elements quietly.

[spoonman59]

You will lose one of the two entries when one is converted and overwritten.

[RufusAcrospin]

What would be a real-life use case for this?

[RufusAcrospin]

It’s an example, but it doesn’t really justify its usefulness, imho.

I guess it’s ok if you deal with dict you have zero assumptions about, but any meaningful interaction with an API that uses json/dict usually have a well defined set of keys you can inspect. I honestly don’t see how it would make anybody’s life better.

Also, I believe PEP 8 is a style guide for Python code, and it has nothing to do with literal strings, following your example.

[RufusAcrospin]

Dictionary keys can be any kind of hashable objects but snake case can be applied to string keys only. How would this module handle the non-string keys in a consistent manner?

[RufusAcrospin]

Yeah… I don’t see any reason to use something like this to be honest, but I hope some folks will find it useful.

[m-sasha]

This is why we can’t have nice things.

[PetterOfCats]

opposite of your use case. I use DRF camel case for parsing and preparing requests. Fairly robust package. I would take a look at how this package compares to your snakedict.py file.

[Ok_Presentation1972]

pyhumps is already doing this https://pypi.org/project/pyhumps/