Mailing List Archive

On 2023-12-05 14:37, Chris Green via Python-list wrote:
> Is there a neat, pythonic way to store values which are 'sometimes'
> changed?
>
> My particular case at the moment is calibration values for ADC inputs
> which are set by running a calibration program and used by lots of
> programs which display the values or do calculations with them.
>
> From the program readability point of view it would be good to have a
> Python module with the values in it but using a Python program to
> write/update a Python module sounds a bit odd somehow.
>
> I could simply write the values to a file (or a database) and I
> suspect that this may be the best answer but it does make retrieving
> the values different from getting all other (nearly) constant values.
>
> Are there any Python modules aimed specifically at this sort of
> requirement?
>
Some kind of key/value store sounds like the correct solution. I
wouldn't go as far a database - that's overkill for a few calibration
values.

I might suggest TOML, except that Python's tomllib (Python 3.11+) is
read-only!

Personally, I'd go for lines of:

key1: value1
key2: value2

Simple to read, simple to write.

--
https://mail.python.org/mailman/listinfo/python-list

On 12/5/23 07:37, Chris Green via Python-list wrote:
> Is there a neat, pythonic way to store values which are 'sometimes'
> changed?
>
> My particular case at the moment is calibration values for ADC inputs
> which are set by running a calibration program and used by lots of
> programs which display the values or do calculations with them.
>
> From the program readability point of view it would be good to have a
> Python module with the values in it but using a Python program to
> write/update a Python module sounds a bit odd somehow.
>
> I could simply write the values to a file (or a database) and I
> suspect that this may be the best answer but it does make retrieving
> the values different from getting all other (nearly) constant values.
>
> Are there any Python modules aimed specifically at this sort of
> requirement?

A search term to look for is "data persistence"

there is lots of support at various levels - you can do simpler things
with plain text (or binary), json data, or csv data, or configparser, or
use pickles; if there's not a lot of values a dbapi database may, as
already mentioned, be overkill.

--
https://mail.python.org/mailman/listinfo/python-list

> On 5 Dec 2023, at 14:37, Chris Green via Python-list <python-list@python.org> wrote:
>
> Are there any Python modules aimed specifically at this sort of
> requirement?

I tend to use JSON for this type of thing.
Suggest that you use the options to pretty print the json that is saved so that a human can read it.

For example:
----
import json

config = {
'key2': 42,
'key1': 'value 1',
}

print(json.dumps(config, indent=4, separators=(', ', ': '), sort_keys=True))

----
% python $T/a.py
{
"key1": "value 1",
"key2": 42
}

Barry

--
https://mail.python.org/mailman/listinfo/python-list

On 12/6/23 03:37, Chris Green via Python-list wrote:
> Is there a neat, pythonic way to store values which are 'sometimes'
> changed?
>
> My particular case at the moment is calibration values for ADC inputs
> which are set by running a calibration program and used by lots of
> programs which display the values or do calculations with them.
>
> From the program readability point of view it would be good to have a
> Python module with the values in it but using a Python program to
> write/update a Python module sounds a bit odd somehow.
>
> I could simply write the values to a file (or a database) and I
> suspect that this may be the best answer but it does make retrieving
> the values different from getting all other (nearly) constant values.
>
> Are there any Python modules aimed specifically at this sort of
> requirement?

Another programming-term for these might be "environment variables".
However, be aware that such also has a specific meaning at the Operating
System level.

1 Sysops Environment Variables exist completely outside the code. Python
interrogates the Sysops to fetch/set them. Can be problematic because
only apply on single machine and are not part of change-control, VS, etc.

2 A .con file (in my tradition, likely still .uni type in MSFT) or
similar, which contains the key:value pairs recommended elsewhere. There
are formal .con and .uni (etc) formats. Most of the teams I've
worked-with recently seem to settle on .JSON files which are
very-conveniently structured as (read into/written from) a Python
dictionary, and a single function-call interaction.

Word of warning/voice of [bitter] experience: ALWAYS *trumpet* any
changes in these values AND output them (as you would any "assumptions"
for a calculation) at the top of output reports. The trouble is that
humans assume continuity but such an arrangement is NOT idempotent -
which leads to complaints: "I ran it on Monday and got these results,
but when I ran it again on Tuesday, the results changed"...

Yes there are Python libraries. Choose your method/format first, and
then search - either Duckboards or straight from Pepi.

I have systems which use an DBMS for environment variables, but (a) only
when there's a significant number, and (b) when the application is
already connecting to the DBMS for processing [.and maybe (c) because I
know my way around such tools so they're 'easy']. Not recommended!

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Apologies: neglected suggested web.refs:

https://datagy.io/python-environment-variables/
https://pypi.org/project/json_environ/

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

On 12/5/2023 11:50 AM, MRAB via Python-list wrote:
> On 2023-12-05 14:37, Chris Green via Python-list wrote:
>> Is there a neat, pythonic way to store values which are 'sometimes'
>> changed?
>>
>> My particular case at the moment is calibration values for ADC inputs
>> which are set by running a calibration program and used by lots of
>> programs which display the values or do calculations with them.
>>
>>  From the program readability point of view it would be good to have a
>> Python module with the values in it but using a Python program to
>> write/update a Python module sounds a bit odd somehow.
>>
>> I could simply write the values to a file (or a database) and I
>> suspect that this may be the best answer but it does make retrieving
>> the values different from getting all other (nearly) constant values.
>>
>> Are there any Python modules aimed specifically at this sort of
>> requirement?
>>
> Some kind of key/value store sounds like the correct solution. I
> wouldn't go as far a database - that's overkill for a few calibration
> values.
>
> I might suggest TOML, except that Python's tomllib (Python 3.11+) is
> read-only!
>
> Personally, I'd go for lines of:
>
>     key1: value1
>     key2: value2
>
> Simple to read, simple to write.

Just go with an .ini file. Simple, well-supported by the standard
library. And it gives you key/value pairs.

--
https://mail.python.org/mailman/listinfo/python-list

Thomas Passin <list1@tompassin.net> wrote:
> On 12/5/2023 11:50 AM, MRAB via Python-list wrote:
> > On 2023-12-05 14:37, Chris Green via Python-list wrote:
> >> Is there a neat, pythonic way to store values which are 'sometimes'
> >> changed?
> >>
> >> My particular case at the moment is calibration values for ADC inputs
> >> which are set by running a calibration program and used by lots of
> >> programs which display the values or do calculations with them.
> >>
> >>  From the program readability point of view it would be good to have a
> >> Python module with the values in it but using a Python program to
> >> write/update a Python module sounds a bit odd somehow.
> >>
> >> I could simply write the values to a file (or a database) and I
> >> suspect that this may be the best answer but it does make retrieving
> >> the values different from getting all other (nearly) constant values.
> >>
> >> Are there any Python modules aimed specifically at this sort of
> >> requirement?
> >>
> > Some kind of key/value store sounds like the correct solution. I
> > wouldn't go as far a database - that's overkill for a few calibration
> > values.
> >
> > I might suggest TOML, except that Python's tomllib (Python 3.11+) is
> > read-only!
> >
> > Personally, I'd go for lines of:
> >
> >     key1: value1
> >     key2: value2
> >
> > Simple to read, simple to write.
>
> Just go with an .ini file. Simple, well-supported by the standard
> library. And it gives you key/value pairs.
>
My requirement is *slightly* more complex than just key value pairs,
it has one level of hierarchy, e.g.:-

KEY1:
a: v1
c: v3
d: v4
KEY2:
a: v7
b: v5
d: v6

Different numbers of value pairs under each KEY.

--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list

Paul Rubin <no.email@nospam.invalid> wrote:
> Chris Green <cl@isbd.net> writes:
> > I could simply write the values to a file (or a database) and I
> > suspect that this may be the best answer but it does make retrieving
> > the values different from getting all other (nearly) constant values.
>
> I've used configparser for this, though its intention is files that are
> manually edited, rather than updated by a program.
>
> You can also read and dump a json file or pickle file. I prefer json to
> pickle for most purposes these days.
>
> I don't like YAML and I don't like the proliferation of markup formats
> of this type. So while I don't know exactly what TOML is, I figure it
> must be bad.
>
> I sometimes use ast.literal_eval though it is Python specific.
>
That's interesting, I'll add it to my armoury anyway. :-)


> Of course there is also sqlite but that is probably overkill.

It's what my current code uses but does feel a bit OTT and it isn't
particularly convenient to view when debugging.

--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list

Thank you everyone for all the suggestions, I now have several
possibilities to follow up. :-)

--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-06 at 09:32:02 +0000,
Chris Green via Python-list <python-list@python.org> wrote:

> Thomas Passin <list1@tompassin.net> wrote:

[...]

> > Just go with an .ini file. Simple, well-supported by the standard
> > library. And it gives you key/value pairs.
> >
> My requirement is *slightly* more complex than just key value pairs,
> it has one level of hierarchy, e.g.:-
>
> KEY1:
> a: v1
> c: v3
> d: v4
> KEY2:
> a: v7
> b: v5
> d: v6
>
> Different numbers of value pairs under each KEY.

INI files have sections.

See <https://en.wikipedia.org/wiki/INI_file#Sections>.
--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-06, Stefan Ram wrote:
> Chris Green <cl@isbd.net> writes:
>> KEY1:
>> a: v1
>> c: v3
>> d: v4
>> KEY2:
>> a: v7
>> b: v5
>> d: v6
>
> That maps nicely to two directories with three files
> (under an application-specific configuration directory).

Or an .ini file with two sections (although I don't think you can re-use
key-names in a single ini file)


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
--
https://mail.python.org/mailman/listinfo/python-list

> On 6 Dec 2023, at 09:32, Chris Green via Python-list <python-list@python.org> wrote:
>
> My requirement is *slightly* more complex than just key value pairs,
> it has one level of hierarchy, e.g.:-
>
> KEY1:
> a: v1
> c: v3
> d: v4
> KEY2:
> a: v7
> b: v5
> d: v6
>
> Different numbers of value pairs under each KEY.

JSON will allow you to nest dictionaries.

{
'KEY1': {
'a': v1
'c': v3
'd': v4
}
'KEY2': {
'a': v7
'b': v5
'd': v6
}
}

Personally I would not use .ini style these days as the format does not include type of the data.

Also I would not use the ast.literal_eval as it makes debugging errors in the data harder.

Barry

--
https://mail.python.org/mailman/listinfo/python-list

On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
>
>
>> On 6 Dec 2023, at 09:32, Chris Green via Python-list <python-list@python.org> wrote:
>>
>> My requirement is *slightly* more complex than just key value pairs,
>> it has one level of hierarchy, e.g.:-
>>
>> KEY1:
>> a: v1
>> c: v3
>> d: v4
>> KEY2:
>> a: v7
>> b: v5
>> d: v6
>>
>> Different numbers of value pairs under each KEY.
>
> JSON will allow you to nest dictionaries.
>
> {
> 'KEY1': {
> 'a': v1
> 'c': v3
> 'd': v4
> }
> 'KEY2': {
> 'a': v7
> 'b': v5
> 'd': v6
> }
> }
>
> Personally I would not use .ini style these days as the format does not include type of the data.

Neither does JSON. Besides, JSON is more complicated than necessary
here - in fact, your example isn't even legal JSON since lines are
missing commas.

Fun fact - for at least some, maybe most, JSON files, using eval() on
them is hugely faster than using Python's standard JSON library. I
learned this when I wanted to ingest a large browser bookmarks JSON
file. It wouldn't matter for a much smaller file, of course.

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-06 12:23, Thomas Passin via Python-list wrote:
> On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
>>
>>
>>> On 6 Dec 2023, at 09:32, Chris Green via Python-list <python-list@python.org> wrote:
>>>
>>> My requirement is *slightly* more complex than just key value pairs,
>>> it has one level of hierarchy, e.g.:-
>>>
>>> KEY1:
>>> a: v1
>>> c: v3
>>> d: v4
>>> KEY2:
>>> a: v7
>>> b: v5
>>> d: v6
>>>
>>> Different numbers of value pairs under each KEY.
>>
>> JSON will allow you to nest dictionaries.
>>
>> {
>> 'KEY1': {
>> 'a': v1
>> 'c': v3
>> 'd': v4
>> }
>> 'KEY2': {
>> 'a': v7
>> 'b': v5
>> 'd': v6
>> }
>> }
>>
>> Personally I would not use .ini style these days as the format does not include type of the data.
>
> Neither does JSON. Besides, JSON is more complicated than necessary
> here - in fact, your example isn't even legal JSON since lines are
> missing commas.
>
> Fun fact - for at least some, maybe most, JSON files, using eval() on
> them is hugely faster than using Python's standard JSON library. I
> learned this when I wanted to ingest a large browser bookmarks JSON
> file. It wouldn't matter for a much smaller file, of course.
>
It would be safer if you used literal_eval.
--
https://mail.python.org/mailman/listinfo/python-list

On 7/12/23 07:12, MRAB via Python-list wrote:
> On 2023-12-06 12:23, Thomas Passin via Python-list wrote:
>> On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
>>>
>>>
>>>> On 6 Dec 2023, at 09:32, Chris Green via Python-list
>>>> <python-list@python.org> wrote:
>>>>
>>>> My requirement is *slightly* more complex than just key value pairs,
>>>> it has one level of hierarchy, e.g.:-
>>>>
>>>>     KEY1:
>>>>       a: v1
>>>>       c: v3
>>>>       d: v4
>>>>     KEY2:
>>>>       a: v7
>>>>       b: v5
>>>>       d: v6
>>>>
>>>> Different numbers of value pairs under each KEY.
>>>
>>> JSON will allow you to nest dictionaries.
>>>
>>> {
>>>      'KEY1': {
>>>          'a': v1
>>>          'c': v3
>>>          'd': v4
>>>      }
>>>      'KEY2': {
>>>           'a': v7
>>>           'b': v5
>>>           'd': v6
>>>      }
>>> }
>>>
>>> Personally I would not use .ini style these days as the format does
>>> not include type of the data.
>>
>> Neither does JSON.  Besides, JSON is more complicated than necessary
>> here - in fact, your example isn't even legal JSON since lines are
>> missing commas.
>>
>> Fun fact - for at least some, maybe most, JSON files, using eval() on
>> them is hugely faster than using Python's standard JSON library.  I
>> learned this when I wanted to ingest a large browser bookmarks JSON
>> file. It wouldn't matter for a much smaller file, of course.
>>
> It would be safer if you used literal_eval.

Ah, memories of Python2...

Does this little hack still work?

What about True/False cf true/false?

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

On 12/6/2023 1:12 PM, MRAB via Python-list wrote:
> On 2023-12-06 12:23, Thomas Passin via Python-list wrote:
>> On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
>>>
>>>
>>>> On 6 Dec 2023, at 09:32, Chris Green via Python-list
>>>> <python-list@python.org> wrote:
>>>>
>>>> My requirement is *slightly* more complex than just key value pairs,
>>>> it has one level of hierarchy, e.g.:-
>>>>
>>>>     KEY1:
>>>>       a: v1
>>>>       c: v3
>>>>       d: v4
>>>>     KEY2:
>>>>       a: v7
>>>>       b: v5
>>>>       d: v6
>>>>
>>>> Different numbers of value pairs under each KEY.
>>>
>>> JSON will allow you to nest dictionaries.
>>>
>>> {
>>>      'KEY1': {
>>>          'a': v1
>>>          'c': v3
>>>          'd': v4
>>>      }
>>>      'KEY2': {
>>>           'a': v7
>>>           'b': v5
>>>           'd': v6
>>>      }
>>> }
>>>
>>> Personally I would not use .ini style these days as the format does
>>> not include type of the data.
>>
>> Neither does JSON.  Besides, JSON is more complicated than necessary
>> here - in fact, your example isn't even legal JSON since lines are
>> missing commas.
>>
>> Fun fact - for at least some, maybe most, JSON files, using eval() on
>> them is hugely faster than using Python's standard JSON library.  I
>> learned this when I wanted to ingest a large browser bookmarks JSON
>> file. It wouldn't matter for a much smaller file, of course.
>>
> It would be safer if you used literal_eval.

He's going to be writing his own calibration data files, though, so it
should be safe for his purposes.

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-06 20:11, dn via Python-list wrote:
> On 7/12/23 07:12, MRAB via Python-list wrote:
>> On 2023-12-06 12:23, Thomas Passin via Python-list wrote:
>>> On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
>>>>
>>>>
>>>>> On 6 Dec 2023, at 09:32, Chris Green via Python-list
>>>>> <python-list@python.org> wrote:
>>>>>
>>>>> My requirement is *slightly* more complex than just key value pairs,
>>>>> it has one level of hierarchy, e.g.:-
>>>>>
>>>>>     KEY1:
>>>>>       a: v1
>>>>>       c: v3
>>>>>       d: v4
>>>>>     KEY2:
>>>>>       a: v7
>>>>>       b: v5
>>>>>       d: v6
>>>>>
>>>>> Different numbers of value pairs under each KEY.
>>>>
>>>> JSON will allow you to nest dictionaries.
>>>>
>>>> {
>>>>      'KEY1': {
>>>>          'a': v1
>>>>          'c': v3
>>>>          'd': v4
>>>>      }
>>>>      'KEY2': {
>>>>           'a': v7
>>>>           'b': v5
>>>>           'd': v6
>>>>      }
>>>> }
>>>>
>>>> Personally I would not use .ini style these days as the format does
>>>> not include type of the data.
>>>
>>> Neither does JSON.  Besides, JSON is more complicated than necessary
>>> here - in fact, your example isn't even legal JSON since lines are
>>> missing commas.
>>>
>>> Fun fact - for at least some, maybe most, JSON files, using eval() on
>>> them is hugely faster than using Python's standard JSON library.  I
>>> learned this when I wanted to ingest a large browser bookmarks JSON
>>> file. It wouldn't matter for a much smaller file, of course.
>>>
>> It would be safer if you used literal_eval.
>
> Ah, memories of Python2...
>
> Does this little hack still work?
>
> What about True/False cf true/false?
>
Nope, nor None cf null.

If it's numbers, strings, lists and dicts, it works.

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-06 07:23:51 -0500, Thomas Passin via Python-list wrote:
> On 12/6/2023 6:35 AM, Barry Scott via Python-list wrote:
> > Personally I would not use .ini style these days as the format does not include type of the data.
>
> Neither does JSON.

Well, it distinguishes between some primitive types (string, number,
boolean, null) and provides two container types (dict/object,
list/array). As long as those types are sufficient, JSON includes them.
If you need anything else, you're on your own.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote:

> The biggest caveat is that the shared variable MUST exist before it can
> be examined or used (not surprising).

There are a few other questions. Let's say config.py contains a variable
like 'font' that is a user set preference or a calibration value
calculated by A to keep with the thread title. Assuming both scripts are
running, how does the change get propagated to B after it is set in A and
written to the shared file? Is there a mechanism to allow both scripts to
make updates?

The easy way out is to assume the changes will be picked up when the
scripts are restarted but this is not always acceptable.

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-28 05:20:07 +0000, rbowman via Python-list wrote:
> On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote:
> > The biggest caveat is that the shared variable MUST exist before it can
> > be examined or used (not surprising).
>
> There are a few other questions. Let's say config.py contains a variable
> like 'font' that is a user set preference or a calibration value
> calculated by A to keep with the thread title. Assuming both scripts are
> running, how does the change get propagated to B after it is set in A

It isn't. The variable is set purely in memory. This is a mechanism to
share a value between multiple modules used by the same process, not to
share between multiple processes (whether they run the same or different
scripts)

> and written to the shared file?

Nothing is ever written to a file.

You could of course write python files from a python script (in fact I
do this), but that's not what this pattern is about, AFAICS.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 12/28/2023 12:20 AM EST rbowman via Python-list
<[1]python-list@python.org> wrote:


On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote:


The biggest caveat is that the shared variable MUST exist before it
can
be examined or used (not surprising).

There are a few other questions. Let's say config.py contains a variable
like 'font' that is a user set preference or a calibration value
calculated by A to keep with the thread title. Assuming both scripts are
running, how does the change get propagated to B after it is set in A
and
written to the shared file? Is there a mechanism to allow both scripts
to
make updates?

The easy way out is to assume the changes will be picked up when the
scripts are restarted but this is not always acceptable.

--
[2]https://mail.python.org/mailman/listinfo/python-list

If one module does a:

import config

config.font = "New Value"

Then every other module in that program that also did a

import config

will see the new value of that variable, as the assignment rebound the
name in the module namespace to the new value.

Note, it does NOT work if you did a

from config import font

font = "New Value"



as that doesn't change the binding in the config module.

IF you need to propagate to a different process, you need something
different.


References

Visible links
1. mailto:python-list@python.org
2. https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list

First, one of the posters got it right. Nothing is REALLY ever "written"
to the file. Consider it a global variable that isn't a global variable.

Assume you have two modules, A and B. Both modules import config.
Furthermore, let's assume that Module B 'writes' a variable called "font"...

shared.font="TkDefaultFont"

That information is immediately available to Module A. All Module A has to
do is (assuming that it has been initialized previously) do something like
this...

myFont=shared.font

Now, myFont has the value "TkDefaultFont" in both modules A and B.

Further, let's assume that we need to pass a ttk::Theme to Module B...
Module A does a
shared.currentTheme = "clam"

Anytime Module B wants to check the value of the shared variable, it can
do...

MyCurrentTheme = shared.currentTheme.

You can also use a similar variable that will hold a flag boolean "saying"
something like

shared.UpdatedInfo = True

This can be tested at any time via any timer check, including a Tkinter
root.after type timer. If the timer is true, simply go through your list
of shared variables (You should keep them in a list just to be sure) then
they can be checked on a timed basis. Or just use ...

MyVariable=shared.VariableName anytime you need to make sure it's updated.
If the value is the same, it only wastes a few clock cycles. However if it
has been updated, then you got the latest version.

This can work for any number of modules. You aren't limited to just two.

I hope this helps.

Greg
--
*My memory check bounced*



Greg Walters
--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-28, Peter J. Holzer via Python-list <python-list@python.org> wrote:
> On 2023-12-28 05:20:07 +0000, rbowman via Python-list wrote:
>> On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote:
>> > The biggest caveat is that the shared variable MUST exist before it can
>> > be examined or used (not surprising).
>>
>> There are a few other questions. Let's say config.py contains a variable
>> like 'font' that is a user set preference or a calibration value
>> calculated by A to keep with the thread title. Assuming both scripts are
>> running, how does the change get propagated to B after it is set in A
>
> It isn't. The variable is set purely in memory. This is a mechanism to
> share a value between multiple modules used by the same process, not to
> share between multiple processes (whether they run the same or different
> scripts)
>
>> and written to the shared file?
>
> Nothing is ever written to a file.

Then how does it help the OP to propogate clibration values from one
program to another or from one program run to the next run?

> You could of course write python files from a python script (in fact I
> do this), but that's not what this pattern is about, AFAICS.


--
https://mail.python.org/mailman/listinfo/python-list

On 2023-12-29 09:01:24 -0800, Grant Edwards via Python-list wrote:
> On 2023-12-28, Peter J. Holzer via Python-list <python-list@python.org> wrote:
> > On 2023-12-28 05:20:07 +0000, rbowman via Python-list wrote:
> >> On Wed, 27 Dec 2023 03:53:42 -0600, Greg Walters wrote:
> >> > The biggest caveat is that the shared variable MUST exist before it can
> >> > be examined or used (not surprising).
> >>
> >> There are a few other questions. Let's say config.py contains a variable
> >> like 'font' that is a user set preference or a calibration value
> >> calculated by A to keep with the thread title. Assuming both scripts are
> >> running, how does the change get propagated to B after it is set in A
> >
> > It isn't. The variable is set purely in memory. This is a mechanism to
> > share a value between multiple modules used by the same process, not to
> > share between multiple processes (whether they run the same or different
> > scripts)
> >
> >> and written to the shared file?
> >
> > Nothing is ever written to a file.
>
> Then how does it help the OP to propogate clibration values from one
> program to another or from one program run to the next run?

It doesn't. See his second mail in this thread, where he explains it in
a bit more detail. I think he might be a bit confused in his
terminology.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"