Re: Is there a better way? [combining f-string, thousands separator, right align]
On 26/08/24 03:12, Gilmeh Serda via Python-list wrote:
Subject explains it, or ask.
This is a bloody mess:
s = "123456789" # arrives as str
f"{f'{int(s):,}': >20}"
' 123,456,789'
With recent improvements to the expressions within F-strings, we can
separate the string from the format required. (reminiscent of FORTRAN
which had both WRITE and FORMAT statements, or for that matter HTML
which states the 'what' and CSS the 'how')
Given that the int() instance-creation has a higher likelihood of
data-error, it is recommended that it be a separate operation for ease
of fault-finding - indeed some will want to wrap it with try...except.
>>> s = "123456789" # arrives as str
>>> s_int = int( s ) # makes the transformation obvious and distinct
>>> s_format = ">20," # define how the value should be presented
>>> F"{s_int:{s_format}}"
' 123,456,789'
Further, some of us don't like 'magic-constants', hence (previously):
>>> S_FIELD_WIDTH = 20
>>> s_format = F">{S_FIELD_WIDTH},"
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!
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way? [combining f-string, thousands separator, right align]
On 2024-08-26 at 20:42:32 +1200,
dn via Python-list 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.
--
https://mail.python.org/mailman/listinfo/python-list
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 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
--
https://mail.python.org/mailman/listinfo/python-list
Re: new here
On Sun, 25 Aug 2024 21:29:30 -0400, avi.e.gross wrote: > If everyone will pardon my curiosity, who and what purposes are these > smaller environments for and do many people use them? > > I mean the price of a typical minimal laptop is not a big deal today. So > are these for some sort of embedded uses? > > I read about them ages ago but wonder ... Typically they are used for I/O with the physical world. Some, like the Arduino Nano Sense, have a number of sensors on the board including a 9 axis inertial, temperature, humidity, barometric, microphone, light intensity, and color sensors. MIT chose this for their TinyML course because it was one-stop shopping. Using TinyML, a really cut down version of TensorFlow, gesture, wake word, image recognition, and other tasks were move entirely to the edge device. Others, like the Pico series, bring out the I/O pins but have little onboard. Many pins are multi-purpose and are used for SPI or I2C protocols, PWM, A/D measurements, and plain vanilla digital. The Raspberry Pi series lives in both worlds. Particularly with the new Pi 5, it's usable as a desktop Linux system, if somewhat limited, while bringing out the PIO pins. It's really a different world than a typical laptop. Years (decades?) ago you could subvert the parallel port controller to provide digital I/O but who has seen a parallel port lately? There are many families and devices available that are used for any number of projects that need to interact with the real world. The earliest variants were usually programmed in assembler since 2k of EPROM and 128 bytes of RAM was typical. As they improved C was sued. Now there's enough flash and SRAM to support MicroPython or CircuitPython and they are fast enough for most purposes. There are specialized drivers but if you know Python the bulk of the logic will be very familiar. For example I have a desktop Python app that pulls weather data from NOAA's web API. The Pico W has Wifi, so if I wanted to compare NOAA's temperature, humidity, and barometric pressure to the values I read from a local sensor, the API requests and parsing the JSON reply would be almost identical to the desktop code. Conversely I could use the Pico W as a web server to make its sensor reading available. -- https://mail.python.org/mailman/listinfo/python-list
Re: Triggered By Mediocre Code (Posting On Python-List Prohibited)
On Sun, 25 Aug 2024 23:49:48 - (UTC), Lawrence D'Oliveiro wrote: > The irony of my putdown is that PHP can do it about as simply. But don’t > expect your typical PHP programmers to know that ... It has had amazing longevity for something that was born as Personal Home Page. -- https://mail.python.org/mailman/listinfo/python-list
