You’re correct but the templates weren’t wrong when they were first composed. Something must have changed in the interim. Whatever it was, I didn’t see it mentioned as a breaking change (it definitely broke this template).
Seeing that no one can replicate the failure of strptime when used in a python_script, and no one has replied to the GitHub Issue (and probably never will), it’s safe to say anyone who has the misfortune of experiencing this problem must forego its use.
I’ve replaced strptime with some parsing code; it’s not nearly as feature-complete or convenient but it does the job.
A working python_script that inexplicably loses use of the strptime function. I haven’t had any significant reliability problems in over 2 years of operation but this one takes the cake.
I’m confused by the last line of your quoted post where you indicate you “don’t think this is related to any issue’s you guys are running into”. Are you saying you now believe it is the cause?
If so, that clears up the issue raised by acraigbray (and isn’t due to any fault of strptime but the new time format used by sun.sun).
What remains unresolved is the failure of strptime in a python_script on one instance of Home Assistant which considers it to be part of an external module (when it isn’t external on other instances of Home Assistant). The bug even survives upgrades/downgrades of Home Assistant. Puzzling to say the least.
No, looking at the code (You can do this yourself), none of the changes indicate anything in the sun integration was changed other than the main method of timezone localization in the dt utility. I don’t have that memorized, I doubt any dev’s have it memorized. You’re welcome to dive right in and assert that this PR is the cause.
Of course there is code above and below my snipet but it is the strptime line that is causing the error.
It generates the following error.
Logger: homeassistant.components.python_script.unavailable_entities.py
Source: components/python_script/__init__.py:224
Integration: Python Scripts (documentation, issues)
First occurred: 11:30:22 AM (3 occurrences)
Last logged: 11:38:25 AM
Error executing script: '__import__'
Error executing script: name 'strptime' is not defined
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/python_script/__init__.py", line 224, in execute
exec(compiled.code, restricted_globals)
File "unavailable_entities.py", line 76, in <module>
KeyError: '__import__'
I have spent hours to figure out a work around to no avail.
Any suggestions would be very welcome.
thanks in advance.
Hello, I have just encountered the same problem - a python script which used datetime.strptime has been working fine for over a year has decided to stop working after an update to the latest Home Assistant.
2023-02-23 21:05:09.285 ERROR (SyncWorker_5) [homeassistant.components.python_script.kitchen_nightlight.py] Error executing script: '__import__'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/python_script/__init__.py", line 224, in execute
exec(compiled.code, restricted_globals)
File "kitchen_nightlight.py", line 82, in <module>
KeyError: '__import__'
Calls to other datetime methods (eg. datetime.now()) work fine, so the module exists, just not strptime. Much like Taras, I can see no issues with the install or other changes which might have triggered this, nor can I find anything in the update’s changelogs, or the actual logs.
BUT I do offer a small beacon of hope: if you’re trying to strptime() from a DateTime helper, then helper’s state is stored in iso format, which means you can replace strptime with fromisoformat():
for whatever reason, this function works fine. Hopefully someone will track down the underlying issue eventually, but this is a good enough workaround for me right now.