Re: Is there a better way? [combining f-string, thousands separator, right align]

On 26/08/24 23:00, Dan Sommers via Python-list wrote:

On 2024-08-26 at 20:42:32 +1200,
dn via Python-list <python-list@python.org> wrote:
 

and if we really want to go over-board:
>

RIGHT_JUSTIFIED = ">"
THOUSANDS_SEPARATOR = ","
s_format = F"{RIGHT_JUSTIFIED}{S_FIELD_WIDTH}{THOUSANDS_SEPARATOR}"

>
or (better) because right-justification is the default for numbers:
>

s_format = F"{S_FIELD_WIDTH}{THOUSANDS_SEPARATOR}"

>
>
To the extreme that if your user keeps fiddling with presentations (none
ever do, do they?), all settings to do with s_format could be added to a
config/environment file, and thus be even further separated from
program-logic!

 And then you'll need a parser, many of whose Unique Challenges™ aren't
even apparent until you start parsing files from actual users, and
you'll still need some sort of fallback in the code anyway for the case
that s_format can't be parsed (for whatever reason).
 Isn't a config file what just caused the global CrowdStrike outage?  ;-)
 That said, I understand that report generators are a thing, not to
mention RPG (https://en.wikipedia.org/wiki/IBM_RPG).
 Okay, sorry; I'll just crawl back into the hole from whence I came.

Not at all. Please continue to question/ask/suggest!
This is a valid point. There are costs and benefits (trade-offs) to all decisions!
That said, writing one's own parser would become a veritable can of worms/rabbit hole. Here be dragons!
Similarly, explaining this takes longer than writing the example itself!
Older Windows users will know about .ini files, and Linux Admins are familiar with .conf files. Many of us are already using JSON or YAML formats. Any of these (and more) could be pressed into service, as above. At the 'top end', there are also whole libraries devoted to establishing application configuration or "environments": default values, config files, command-line options, user-input...
Have switched to using Python-poetry, which replaces packaging methods such as setuptools (as well as virtual-environment tools). It takes its project configuration specifications from a pyproject.toml file. So, for a few projects lately, I've been using .toml for application-config as well. However, I have to say, this more from an attempt at consistency than a decision of logic. (critique welcome)
That said, a setup.py configuration, took the form:
setup(
     name='demo_project',
     version='1.1.0',
     packages=find_packages(),
     install_requires=[
         'requests',
         'numpy',
         ...
     ],
     entry_points={
...
Accordingly, it offers an example of the simplest format (for us), and one which has a zero-learning pre-requisite. At execution-time, the moment such a config is import-ed, a syntax-error will immediately bring proceedings to a halt!
I have some stats-wonks as clients. They dabble in programming, but (fortunately) realise their limitations. (usually!) The boss has had to ban them from 'improving' my code ($paid to be an improvement on their usual quality), but including a .py configuration/options file has proven to be an honor-preserving compromise. Of course, they manage their own runs, adjusting parameters as they go. So, any errors are their own, and they can fix themselves (without anyone else knowing!).
Such would not work in many?most other environments - children: do not try this at home!
An irritation for those of us who have to delve into projects after they've been written, is a git-history full of the sorts of user-tweaking changes vilified earlier. Putting user-config into a separate file, even a separate sub-directory, makes it easy to spot which updates to ignore, and thus, which to consider!
PS the reason why CrowdStrike was not the end of humanity as we know it, (and only that of those who only know MSFT's eco-system) is because the majority of the world's Internet servers run Linux - including Azure (brings to mind the old saw: the package said "runs on Windows-95 or better" so I installed it on Linux!)
Joking aside, we (virtuous ones) ALWAYS test BEFORE release. Correct?
--
Regards,
=dn