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.

    • l3mming@lemmy.fmhy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      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
        link
        fedilink
        English
        arrow-up
        1
        ·
        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
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

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

    • Dr. Wesker@lemmy.sdf.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      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
        link
        fedilink
        English
        arrow-up
        6
        ·
        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
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

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

  • lasagna
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    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.

    • Dr. Wesker@lemmy.sdf.orgOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      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!

    • o11c
      link
      fedilink
      English
      arrow-up
      1
      ·
      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.

    • Dr. Wesker@lemmy.sdf.orgOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      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
        link
        fedilink
        English
        arrow-up
        1
        ·
        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.