submitted 1 year ago* (last edited 1 year ago) by wesker@lemmy.sdf.org to c/python@programming.dev

19 comments fedilink hide all child comments

I have a use case where I'd like to store a handful of strings with static values, alongside my code that references them. The general reason for not hard coding them where they're called, is that I'd like to make it easy for the end user to customize and modify them.

Are there any suggestions or comments about the best ways to do this? Storing them in a python file as vars seems reasonable. I've also considered saving them as JSON, though I don't know if there's any benefit to that in this case.

Thoughts are appreciated.

top 16 comments

sorted by: hot top controversial new old

[-] whRQla8GEMdqXW2OVCbS@lemmy.blahaj.zone 6 points 1 year ago

I always use a yaml file for user config but json is fine, too

[-] l3mming@lemmy.fmhy.ml 2 points 1 year ago* (last edited 1 year ago)

Yaml is pure evil with utterly useless syntax checking.

Ever tried maintaining a Swagger file using yaml?

I'm never touching that shit again.

[-] davenull@programming.dev 1 points 1 year ago

YAML is far from perfect but this seems like a hot take. I work with OpenAPI definitions a lot so I'm just curious what you found difficult about maintaining a definition in YAML?

[-] rhacer@lemmy.world 5 points 1 year ago

How many? I probably wouldn't even bother with JSON, just one string per line in a text file.

[-] wesker@lemmy.sdf.org 1 points 1 year ago

Sorry, I should have given more detail about the nature of the strings.

Right now it's about ~15, however that could grow to maybe a maximum of 30. Some are short sentences, but others might be a couple sentences long.

[-] rhacer@lemmy.world 6 points 1 year ago

I'd absolutely use a text file, one entry per line. Once you need to start associating other information with those strings, it becomes time for JSON or similar.

[-] const_void@lemmy.world 5 points 1 year ago

json schema + json allows you to extend beyond key/value pairs & the input validation is "free".

[-] Sigmatics@lemmy.ca 4 points 1 year ago

use configparser if you want user configuration

[-] wesker@lemmy.sdf.org 1 points 1 year ago

This is a great lead, thank you!

[-] lasagna@programming.dev 2 points 1 year ago* (last edited 1 year ago)

If you don't care too much about how it looks then you could just straight up have a Python dictionary in a separate file then just import it into main code.

If you want something more formal looking (or expect rather dumb users) then perhaps something like tkinter that draws default values from a file such as the above. Tkinter can enforce input types and such quite easily too.

[-] wesker@lemmy.sdf.org 2 points 1 year ago

I'm not familiar with tkinter. This is an amazing suggestion. If not for this particular use case, I very well may use it for a completely different one I still need a solve for. Thanks!

[-] TribulateAnxiety@mastodon.online 3 points 1 year ago

@wesker @lasagna customtkinter for visually better interface.

[-] o11c@programming.dev 1 points 1 year ago

Note that by messing with a particular module's __path__ you can turn it into a "package" that loads from arbitrary directories.

[-] ActuallyRuben@actuallyruben.nl 2 points 1 year ago

By any chance, is the reason for this to translate to different languages? If so I'd recommend using hertest. It's a UNIX tool which python has standard library support for: https://docs.python.org/3/library/gettext.html

[-] wesker@lemmy.sdf.org 1 points 1 year ago

It's not, but thank you for the thoughtful response.

I'm building a MUD server framework. I'd like to allow some of the high level event messages easily modified, should the builders/admins desire to have a totally customized experience.

[-] o11c@programming.dev 1 points 1 year ago

Honestly you probably should think about how to translate them. Python at least rolls its own .mo parser so it can support multiple languages in a single process; it's much more difficult in C unless you push it to the clients (which requires pushing the parameterization as well).

Non-.pot-based internationalization formats are almost always braindead and should be avoided.

load more comments