PythonMapper/Public/doc/es/description.md

63 lines
3.9 KiB
Markdown
Raw Permalink Normal View History

Python, a la hora de trabajar con clases-objeto que se van generando en archivos que se van importando, estos archivos importados tienen un problema a la hora de asignar tipados de variables de elementos los cuales los importan, es decir: si tenemos una clase-objeto maestra donde el resto de clases-objeto de la estructura requieren de conocer al maestro, Python, sobre estructuras tipadas, ya sea por asignación voluntaria mediante "typing" como tipado forzoso como *py-py*, éste no puede ser asignado de esta forma por defecto.
> [!#] Un ejemplo de este caso sería el proyecto AnP, cuya filosofía exige un conocimiento de las clases-objetos pertenencientes a la clase-objeto AnP conozcan a dicho objeto que parte de éste último.
Con esta premisa, como se dijo antes, salvo usos específicos contra compiladores tipo *py-py* Python de por sí ignorará los tipados, por lo que si lo que se busca es tener un acceso al CodeDoc de código por parte del IDE a utilizar, se usará un archivo de elementos nulos y/o vacíos e inútiles que mapeen los elementos de dicha clase-objeto maestra, de esta forma no forzamos un tipado anidado por importación la cual es incompatible con Python. En cada librería que creemos implementamos los elementos a utilizar de dicha librería, simpre contando con que no se usen a modo de creación o ciertas características especiales, donde sí tendríamos que importar la librería original, como un modelo u objeto.
Explicando más claramente el problema, si nos basamos en la estructura base de AnP como ejemplo, lo que vemos es claramente que a la hora de importar la librería dependiente de AnP es que se forma un bucle infinito de cargas de dependencias, lo que determina en un error de dependencias en importación en Python.
```mermaid
flowchart LR
subgraph "Nivel 1"
A[AnP]
end
subgraph "Nivel 2"
P[Path]
S[Settings]
I[I18N]
end
A -->|tiene| P
A -->|tiene| S
A -->|tiene| I
P -->|depende de| A
S -->|depende de| A
I -->|depende de| A
S -->|depende de| P
I -->|depende de| P
```
> [!#] En un lenguaje como Java, PHP o Rust, este problema no existe pues una vez se cargan las librerías pertinentes, éstas quedan en ejecución al mismo nivel pero en el caso de Python es como que dichas librerías se ejecutan en un nivel independiente y por lo tanto, se crean niveles de dependencias entre ellos. A continuación se muestra otro gráfico de qué pasaría a la hora de hacer dicha dependencia dentro de AnP.
```mermaid
flowchart TD
A0["AnP original"]
P0["Path original"]
A1["AnP dependencia de nivel 1"]
P1["Path uso de nivel 1"]
A2["AnP dependencia de nivel 2"]
P2["Path uso de nivel 2"]
A3["AnP dependencia de nivel 3"]
P3["Path uso de nivel 3"]
AN(("AnP dependencia \nde nivel N (Infinito)"))
A0 -->|tiene| P0
P0 -->|"depende y carga"| A1
A1 -->|tiene| P1
P1 -->|"depende y carga"| A2
A2 -->|tiene| P2
P2 -->|"depende y carga"| A3
A3 -->|tiene| P3
P3 -->|"depende y carga"| AN
```
> [!! ¡IMPORTANTE!] Desde el equipo de desarrollo de este proyecto queremos matizar que esta filosofía de desarrollo no es eficiente, y no sería aconsejable su uso en proyectos cuya filosofía o motivo de existencia sea la eficiencia y el consumo reducido pues requeriríamos de compilaciones y ejecuciones más orientadas a *py-py*. Este proyecto sólo es viable para proyectos cuya filosofía sea más bien la facilidad cara el desarrollo de aplicaciones que no requieran de una eficiencia importante.
Para solucionar dicho problema y automatizar dicho proceso en dicha casuística, creamos la librería "mapper.py" en el lado del proyecto Python, una librería completamente independiente que nos permita hacer un mapeado automático de los ficheros que nosotros le asignemos.
> [!#] Ya existen librerías e importaciones Python que hace esta tarea pero tanto por aprender cómo sería por debajo uno de estos procesos, así como hacer un uso personalizado del mismo, se decidió crear la librería propia para dicho fin.