Python Problems: Difference between revisions
RogueScholar (talk | contribs) (Fix dead end page status with wikilinks and inline citations, and also −Category:Development; +Category:Python using HotCat) |
No edit summary |
||
Line 6: | Line 6: | ||
There is an old [[Python debugging|Python bug]]<ref name="bug_27400" /> which ''only'' impacts embedded Python applications, such as the Kodi Python environment. The issue is that <code>datetime.strptime</code><ref name="pydocs_datetime" /> is only initialized once per process, and not every time the embedded environment is reinitialized. This causes <code>datetime.strptime</code> to return <code>None</code> (and perhaps other strange behavior). | There is an old [[Python debugging|Python bug]]<ref name="bug_27400" /> which ''only'' impacts embedded Python applications, such as the Kodi Python environment. The issue is that <code>datetime.strptime</code><ref name="pydocs_datetime" /> is only initialized once per process, and not every time the embedded environment is reinitialized. This causes <code>datetime.strptime</code> to return <code>None</code> (and perhaps other strange behavior). | ||
=== | === Workaround === | ||
The workaround is to monkey-patch <code>datetime.strptime</code> so that any user of the Python runtime will use it. It is more voodoo-like, but situations like this are why Python ''natively supports'' [[wikipedia:Monkey patch|monkey patching]], after all. The typically excellent Python documentation manages to be both thorough and concise simultaneously with regards to <code>datetime.strptime</code> and is well worth reviewing before deciding which angle of attack best suits your use case.<ref name="pydocs_strptime" />; it discusses some of the differences between <code>datetime.strptime</code> and <code>time.strptime</code>.<ref name="pydocs_differences" /> | |||
The | |||
=== Patch === | === Patch === | ||
This patch simply replaces <code>datetime.strptime</code> with <code>time.strptime</code> as they are nearly identical in function. The original Kodi-specific implementation and its commit history are available on GitHub as part of <code>script.module.kutils</code>.<ref name="kutils_source" /> Essentially, the patch is: | This patch simply replaces <code>datetime.strptime</code> with <code>time.strptime</code> as they are nearly identical in function. The original Kodi-specific implementation and its commit history are available on GitHub as part of <code>script.module.kutils</code>.<ref name="kutils_source" /> Essentially, the patch is: | ||
<syntaxhighlight lang="python"> | <syntaxhighlight lang="python"> | ||
import datetime | |||
import time | |||
class proxydt(datetime.datetime): | |||
@classmethod | |||
def strptime(cls, date_string, format): | |||
return datetime.datetime(*(time.strptime(date_string, format)[:6])) | |||
@ | |||
def strptime(date_string | |||
datetime.datetime = proxydt | |||
</syntaxhighlight> | </syntaxhighlight> | ||
== asyncio == | |||
It is a known [https://github.com/python/cpython/issues/91375 issue] that <code>asyncio</code> module or rather its C-based implementation does not support embedded Python environments that use sub-interpreters, such as Kodi Python environment. Essentially it means that only one addon can start the event loop by calling <code>asyncio.run()</code> and others will fail with <code>RuntimeError</code>. | |||
=== Workaround === | |||
The workaround is to disable C-based <code>asyncio</code> module and use its pure-Python implementation. This can be done by the following code that should be put at the beginning of your addon entrypoint script: | |||
<syntaxhighlight lang="python"> | |||
import sys | |||
sys.modules['_asyncio'] = None | |||
</syntaxhighlight> | |||
You will loose possible performance benefits of <code>asyncio</code> but your async Python code won't fail. | |||
== References == | == References == |
Latest revision as of 19:44, 1 September 2022
Development | Add-on development | About Add-ons | Python Problems |
This page is meant to document Python issues of general interest to Kodi addon developers.
datetime.strptime
There is an old Python bug[1] which only impacts embedded Python applications, such as the Kodi Python environment. The issue is that datetime.strptime
[2] is only initialized once per process, and not every time the embedded environment is reinitialized. This causes datetime.strptime
to return None
(and perhaps other strange behavior).
Workaround
The workaround is to monkey-patch datetime.strptime
so that any user of the Python runtime will use it. It is more voodoo-like, but situations like this are why Python natively supports monkey patching, after all. The typically excellent Python documentation manages to be both thorough and concise simultaneously with regards to datetime.strptime
and is well worth reviewing before deciding which angle of attack best suits your use case.[3]; it discusses some of the differences between datetime.strptime
and time.strptime
.[4]
Patch
This patch simply replaces datetime.strptime
with time.strptime
as they are nearly identical in function. The original Kodi-specific implementation and its commit history are available on GitHub as part of script.module.kutils
.[5] Essentially, the patch is:
import datetime import time class proxydt(datetime.datetime): @classmethod def strptime(cls, date_string, format): return datetime.datetime(*(time.strptime(date_string, format)[:6])) datetime.datetime = proxydt
asyncio
It is a known issue that asyncio
module or rather its C-based implementation does not support embedded Python environments that use sub-interpreters, such as Kodi Python environment. Essentially it means that only one addon can start the event loop by calling asyncio.run()
and others will fail with RuntimeError
.
Workaround
The workaround is to disable C-based asyncio
module and use its pure-Python implementation. This can be done by the following code that should be put at the beginning of your addon entrypoint script:
import sys sys.modules['_asyncio'] = None
You will loose possible performance benefits of asyncio
but your async Python code won't fail.
References
- ↑ Weinberg, Denny (June 27, 2016). Issue #71587: Datetime NoneType after calling Py_Finalize and Py_Initialize. Python Issue Tracker on GitHub.
- ↑ Python 3 Documentation (August 28, 2022). The Python Standard Library » Data Types » datetime — Basic date and time types ― classmethod datetime.strptime(date_string, format) ― from the source code found in Lib/datetime.py.
- ↑ Python 3 Documentation (August 28, 2022). datetime — Basic date and time types » strftime() and strptime() Behavior.
- ↑ Python 3 Documentation (August 28, 2022). strftime() and strptime() Behavior » Technical Detail.
- ↑ lib/kutils/strptime_patch.py (January 11, 2022) in
script.module.kutils
, "A helper module for Kodi development" on GitHub.