At the moment PyAL
is used across all the Python
based actors (generated via FC2K
). PyAL
provides another layer between Access Layer
and actors.
Event though current solution works it has some flaws:
1.1.1.1. Template
Python
template (FC2K
) is composed of one, large file that is hard to maintain- Lots of information between components is passed via dictionaries instead of strictly defined interfaces
- Logic of the actor is driven by if-else based approach - it's hard to add new features that are not supported at the moment
- Lots of hidden assumptions are made in the code (e.g. temporary files creation, arguments that are responsible for script execution, etc.)
- Error handling is not quite ideal
1.1.1.2. PyAL module
PyAL
module (as a middle layer) seems to be obsolete now. As we plan to push everything towards IMAS
based approach it seems reasonable to put PyAL
features directly into Python
interface, or as an external module that is quite close to Python
HLI
. At the moment, PyAL
is hard to maintain due to:
- parts of code being hardcoded (magic values)
PyAL
serves as yet another level in the whole structure and adds unnecessary complexity to the solution- It should be possible to implement features of
PyAL
using features coming purely fromPython HLI
PyAL
doesn't supportIDS
description based data transfer - it means we have to read/write data between calls to native routines- Changing
PyAL
is a quite hard process. Lots of thing are tangled together via underlaying objects. It means that changing code in one place affects other parts.
1.1.1.3. Workflow
Workflows are the element that will probably require least changes. However it still can be improved.
- We can improve the whole solution such way it is based purely on
IMAS
basedPython HLI
- Once index based (file handler like) exchange of data workflows will require less time and memory to work - there will be no need of exchanging data back and forth between the calls