I have a python script (GUI and pin checking function) that imports a list of pin numbers from another file, checks them against user input and then executes a list of commands if the pin is correct.
One of those commands is a reset of the pin that was used, so, changing the variable data that is stored in the pin numbers file and hopefully in the mainloop that is running but this isn’t happening.
The issue is that the old pin remains stored in the mainloop and the only way to get it to acknowledge the newly set pin is to restart the application so that it newly imports it.
If I run a print statement from outside the mainloop in terminal, I see the correct pin showing after it was reset so again confirming, only a fresh import will display it correctly.
Attempting to get the mainloop to “see” or acknowledge the new pin stored to that variable as the valid one, I’ve tried:
import PINS #(PINS is the file that stores the pins assigned to the relevant variable)
import importlib
importlib.reload(PINS)
but this didn’t work. I’ve also tried creating a function for it
def reload_pins():
importlib.reload(PINS)
then call it later from the end of the if statement
reload_pins()
then lastly I tried using return at the end of the if statement after the reset was done
return variable_storing_the_pin
and this didn’t work either. The only pins the mainloop will accept are those that were loaded when the script was started. It will not recognise any pins that were reset while it was running.
How can I force the reimport of the new pin(s) into the relevant variables if they are changed?
PINS is python file that’s modified? How PINS module is later used in code - does the mainloop use it always directly, or receives relevant pieces only as variables? Does the mainloop and function re-importing module run on a single thread?
Yes PINS.py is the file that is modified. The typical scenario looks something like this:
PINS.py has the pins and looks like this
PIN1 = "9464"
PIN2 = "7240"
The mainloop imports it when launched
from PINS import *
Then a user enters a pin number and the pin checking function checks the entered user pin against the existing pin in the variable
if pin == PIN1:
do stuff and things
pin = '' #clear the entered pin from global variable "pin"
e.delete('0', 'end') #clear the entered pin from GUI interface
subprocess.Popen(['python', 'pin_reset.py']) # execute the reset file which resets that particular pin
(someone suggested to use subprocess.run instead of subprocess.Popen but it didn’t make a difference as far as I could tell)
At this point, the pin number in variable PIN1 has been reset to something else but the pin checking function will still only accept “9464” that was imported when the mainloop was launched unless the mainloop is completely closed and relaunched.
As far as single thread or not, I haven’t imported threading or anything like that. As for “using it directly”, I am not sure what this means. The function reload_pins() that I added wasn’t there before and was only me trying to force it to see the new pin.
The importlib.reload(PINS) will surely not update the references that are imported via from PINS import *, unless they are later reassigned: ie. PIN1 = PINS.PIN1 after the import PINS and reload. That’s a bit inconvenient though.
If mainloop would refer to pins via module name - PINS.PIN1, then it should work. If PINS module only contains data, which is also modified in an external way, it might be good to use different file/format ie. like JSON. It would be simpler to open/load changed JSON file once again, rather than playing with reloading modules.
Thanks a lot for your input here. Including this information so that people know exactly what resolved it:
from PINS import PIN1, PIN2, etc # rather than from PINS import *
import importlib
and in the “if” statements using
if pin == PINS.PIN1 #rather than if pin == PIN1
do stuff and things
reload_pins() # function outside the pin check function using importlib.reload
PIN1 = PINS.PIN1
I didn’t go the way of a .json file since there are many dependencies on the PINS file being a python file. Perhaps something for a later iteration.