Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

2023-12-28 Thread Chris Angelico via Python-list
On Fri, 29 Dec 2023 at 12:23, Félix An via Python-list
 wrote:
>
> On 2023-12-25 12:36, Mike Dewhirst wrote:
> >
> > 3. You cannot trust Microsoft. You can trust Python Software Foundation. 
> > Python from PSF works the same in all environments - or if not it is a bug. 
> > Python from Microsoft is tweaked to satisfy their aforementioned strategy 
> > of locking in users to Windows.
> >
>
> I strongly disagree with this. I don't get all the irrational hate for
> Microsoft that exists within the Linux community.

It's worth noting that Mike Dewhirst is NOT a spokesman for the Linux
community. One of the cool benefits freedom brings is that anyone's
allowed to be wrong :)

Not ALL of us hate Microsoft. I store the vast majority of my code on
GitHub, and it didn't make any difference when MS bought that company
(it was already a company, and their interests were always to make
money, and that was okay with me).

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


Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

2023-12-28 Thread Félix An via Python-list

On 2023-12-25 12:36, Mike Dewhirst wrote:


3. You cannot trust Microsoft. You can trust Python Software Foundation. Python 
from PSF works the same in all environments - or if not it is a bug. Python 
from Microsoft is tweaked to satisfy their aforementioned strategy of locking 
in users to Windows.



I strongly disagree with this. I don't get all the irrational hate for 
Microsoft that exists within the Linux community. In recent years, 
Microsoft has made great contributions to the everyday life of Linux 
users. VS Code is based on open source and available on Linux, .NET is 
now on Linux, Windows has WSL2 and Visual Studio Linux development tools 
to help you develop software for Linux, SQL Server (despite still being 
commercial software except for the Express and Developer versions) is on 
Linux, etc.

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


Are there any easy-to-use Visual Studio C# WinForms-like GUI designers in the Python world for Tk?

2023-12-28 Thread Félix An via Python-list
I'm used to C# WinForms, which has an easy-to-use drag-and-drop GUI 
designer in Visual Studio. Is there anything similar for Tk? How about 
Qt? What do you recommend as the easiest way to create GUI programs in 
Python, similar to the ease of use of C# WinForms?

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


Re: How/where to store calibration values - written by program A, read by program B

2023-12-28 Thread Greg Walters via 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


Re: How/where to store calibration values - written by program A, read by program B

2023-12-28 Thread Richard Damon via Python-list



 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


Re: How/where to store calibration values - written by program A, read by program B

2023-12-28 Thread Peter J. Holzer via Python-list
On 2023-12-28 05:20:07 +, 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.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How/where to store calibration values - written by program A, read by program B

2023-12-28 Thread rbowman via Python-list
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