Article <mailman.10.1724704040.2917.python-list@python.org>

Deutsch English Français Italiano
<mailman.10.1724704040.2917.python-list@python.org>

View for Bookmarking (what is this?)
Look up another Usenet article
Path: ...!fu-berlin.de!uni-berlin.de!not-for-mail
From: dn <PythonList@DancesWithMice.info>
Newsgroups: comp.lang.python
Subject: Re: Is there a better way? [combining f-string, thousands separator, 
 right align]
Date: Tue, 27 Aug 2024 08:27:11 +1200
Organization: DWM
Lines: 108
Message-ID: <mailman.10.1724704040.2917.python-list@python.org>
References: <oRHyO.142039$bV6e.134076@fx08.ams4>
 <09102d57-41cd-4428-b96f-d69e2ffe9c95@DancesWithMice.info>
 <ZsxgUBEdOsVL6c49@anomaly>
 <96f83373-c7ad-4020-96b0-51d956cf433d@DancesWithMice.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cancel-Lock: sha1:cdfwWylqZVsQTwSqxBnaUO4ZE8c= sha256:9TY8qCkh7y2KBO8c37PQ5EsL0U2APy9DnnBGzwAh2lE=
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <ZsxgUBEdOsVL6c49@anomaly>
Precedence: list
Bytes: 9914

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 
========== REMAINDER OF ARTICLE TRUNCATED ==========