Quick list of Python libraries that help with application configuration: - Python application configuration -> https://github.com/edaniszewski/bison - Configuration with env variables for Python -> https://github.com/hynek/environ_config - Configuration library for python projects -> https://github.com/willkg/everett - Strict separation of config from code -> https://github.com/henriquebastos/python-decouple This is…
Best Practices for Working with Configuration in Python Applications
41–50 of 69 posts
Re: Best Practices for Working with Configuration in Python Applications
#42While most points are valid, I feel some pieces are missing in this article. What should I finally do? How to put everything together without creating an hard-to-maintain mess of casting/parsing/configuration? Should I manually cast strings to integers (or other types) for all and each value I parse? Where do I keep default values? It's cumbersome to have them embedded in code for get(). I usually want a) a default c…
Who is the targeted editor of a config file? If it's another programmer, just use config.py and make life easy on yourself.
Re: Best Practices for Working with Configuration in Python Applications
#43Earlier quoted context omitted.
Marshmallow. You can use its schema validation for any dict/json, which makes it a nice fit for validating json config files (which mitigates some of the json concerns from the article). Just immediately move the json.reads through a schema validate, build some classes around it for different config files. marshmallow.readthedocs.io/en/
dataclass_json is also very useful for schema validation. It combines python's native dataclass objects with marshmallow's schema to provide additional functionalities simply through a @dataclass_json decorator on your dataclass. https://lidatong.github.io/dataclasses-json/
I do something similar with dataclasses using the `dacite` (https://github.com/konradhalas/dacite) library as a constructor for python dicts to dataclasses with runtime type-checking.
Works really well with marshmallow for additional validation.
Re: Best Practices for Working with Configuration in Python Applications
#44Along these lines and unsatisfied with current solutions I started this project, "Turtle Config." It is format-agnostic and supports type checking as well:
https://github.com/mixmastamyk/tconf
I'll see if I can add any advice this article gives; feedback would be helpful.
Re: Best Practices for Working with Configuration in Python Applications
#45I have been working on a minimalistic application config library for Python, aiming to consolidate config loading from files, environment variable, and command-line argument parsing. It's an alpha, so please feel free to provide feedback if app configuration has been your pain point.
Re: Best Practices for Working with Configuration in Python Applications
#46Earlier quoted context omitted.
JSON does not support comments nor string interpolation. Python ConfigParser language does.
True, you do get string interpolation but the comment support in ConfigParser isn't very good. Although actually they may have fixed some of that in Python 3 but I'm still using workarounds. To be clear, I am not suggesting using JSON for config, I think that would be my last choice. My point is that ConfigParser isn't really an alternative to rolling your own if you want decent validation etc (those spec files are h…
What's wrong with the comment support?
You can't have comments at the end of a line, but that's sort of the nature of supporting arbitrary strings as values. I don't want my users to have to quote or escape special characters if they happen to want to use them. They're not programmers.
# The note to display
note = Our #1 customer!
name = Our \#1 customer # The note to display.
name = "Our #1 customer" # The note displayRe: Best Practices for Working with Configuration in Python Applications
#47Quick list of Python libraries that help with application configuration: - Python application configuration -> https://github.com/edaniszewski/bison - Configuration with env variables for Python -> https://github.com/hynek/environ_config - Configuration library for python projects -> https://github.com/willkg/everett - Strict separation of config from code -> https://github.com/henriquebastos/python-decouple This is…
There's also confuse[0], used by beets. I've found it to be a good way to handle configuration when the end-user is not a programmer.
Re: Best Practices for Working with Configuration in Python Applications
#48I have been working on a minimalistic application config library for Python, aiming to consolidate config loading from files, environment variable, and command-line argument parsing. It's an alpha, so please feel free to provide feedback if app configuration has been your pain point. https://github.com/okomestudio/resconfig
FYI that sounds like exactly the same feature set of 'python-decouple'.
Re: Best Practices for Working with Configuration in Python Applications
#49Earlier quoted context omitted.
Your assumption is just a guess. Take a look at the python docs I linked just above here: "A naive object does not contain enough information to unambiguously locate itself relative to other date/time objects. Whether a naive object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program"
I'd consider any datetimes that have an implicit timezone that isn't or might not be UTC a bug in any system. This isn't restricted to python. Servers that spit out logs with timestamps, for instance, should be spitting out UTC. It makes sense to build systems that deal with timezones at the very edges (and sometimes not even then) and use UTC for everything else. It's simpler that way.
Unfortunately, in Python, whenever you try to render a datetime "aware" by using the provided conversion method (`astimezone()`) it will assume the naive datetime is in local time zone, not UTC.
The datetime module provides `timezone.utc` to be used whenever you want to have datetimes _in utc_, but it needs to be explicitly used by the programmer.
Re: Best Practices for Working with Configuration in Python Applications
#50Earlier quoted context omitted.
I agree that python datetime objects are problematic, but for the opposite reason. It is tzinfo that is the sneaky disaster, the plain datetimes are fine. Transparent timezone awareness always fail, unless you are 100% certain that a tzaware datetime object will remain uncoverted from the very top to the very bottom of the stack and all the way up again no matter who is reading and what they are doing. For longterm m…
Actually UTC + timezone is exactly the wrong thing for "wall clock times" (things like meetings or departures where the time at the location is relevant). The conversion to UTC will lose the original local time so you cannot retrieve it once time zone data changes, unless you perform reconversions every time you detect such a change in tzdata. And countries changing time zones happens more often than we think (and al…
I believe this "wall clock time" approach is broken by design as it pushes the burden of figuring out timezone details to those who are not located in that particular timezone.
A fair and therefore safer approach is to decide that by protocol the legally binding time is defined in UTC.
Your system will translate UTC times to and from any given local time using the IANA time zone database which is regularly updated. End users must be aware about the UTC time, that it is legally binding, and that the local time conversions are provided as-is.
This way the time of a meeting or deadline is protected from local governments messing around with timezone changes.
Additionally, dates are rendered in ISO8601 standard format with a proper footnote to help users learn about international standards.