refactor(customize): improve code readability

[bearomorphism]

Description

Make the code shorter but still easy to read.

Checklist

• Add test cases to all the changes you introduce
• Run poetry all locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

NA, this is refactor.

Steps to Test This Pull Request

Additional context

NA

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.59%. Comparing base (120d514) to head (e163049).
Report is 608 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1412      +/-   ##
==========================================
+ Coverage   97.33%   97.59%   +0.25%     
==========================================
  Files          42       57      +15     
  Lines        2104     2657     +553     
==========================================
+ Hits         2048     2593     +545     
- Misses         56       64       +8     

Flag	Coverage Δ
unittests	97.59% <100.00%> (+0.25%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bearomorphism]

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

https://chatgpt.com/share/68254494-f83c-8010-8ab3-7f8808682bcf

probably not important

[noirbizarre]

Yes, this one was clearly overly complicated 😅

[noirbizarre]

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

Actually, it matters: if you have some_key: in your settings, meaning empty key in yaml, the key exists and the first one returns None while the second one returns "".
The second approach is most of the time safer is it ensure all falsy values will and with the same type:

yaml	.get("key", "")	.get("key") or ""
Not set	""	""
key: ""	""	""
key:	None	""
key: false	False	""
key: 0	0	""
key: []	[]	""
key: {}	{}	""
key: no (yaml 1.1)	False	""

So it really depends on your case, but if there is no default value, and you want to be sure of the type you have in case of falsy value, go for the 2nd.

[bearomorphism]

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

Actually, it matters: if you have some_key: in your settings, meaning empty key in yaml, the key exists and the first one returns None while the second one returns "". The second approach is most of the time safer is it ensure all falsy values will and with the same type:

yaml .get("key", "") .get("key") or ""
Not set "" ""
key: "" "" ""
key: None ""
key: false False ""
key: 0 0 ""
key: [] [] ""
key: {} {} ""
key: no (yaml 1.1) False ""
So it really depends on your case, but if there is no default value, and you want to be sure of the type you have in case of falsy value, go for the 2nd.

Thank you for explanation. Actually, the thing I'm not sure is if we want to fallback to empty string if the value is falsy (current implementation).