First iteration of the Python parser
## Goal
We want to add support for Python to the [One Parser project.](https://gitlab.com/groups/gitlab-org/-/epics/17516) This will enable knowledge graph construction for Python codebases, as well as other static analysis applications, like chunking code for embeddings.
Given a Python file, the parser should extract:
1. Definitions (functions, classes, and class methods)
2. References (function/method calls, class instantiations)
3. Imports
It should also compute a fully qualified name (FQN) for each one. These will be used to link nodes together in the [Knowledge Graph Indexer.](https://gitlab.com/gitlab-org/rust/knowledge-graph)
### Why imports?
Given a single file, we can only resolve FQNs for references to functions defined in the same file. For references to functions imported from other files, the best our parser can do is trace the reference back to the imported symbol. For example, consider this file:
```python
from .utils import foo
foo()
```
The FQN our parser computes will be `utils.foo`. This is fine, except it doesn't tell us which file `foo` is defined in. Suppose it's defined in `utils/stuff.py` but the `utils` folder has the following `__init__` file:
```python
from .utils.stuff import foo
```
Then the FQN should be `utils.stuff.foo`, not `utils.foo`. This is why our parser must capture imported symbols in addition to definitions and references. The KG Indexer will need them to traverse import chains and resolve FQNs for references to imported functions.
## Limitations
Because Python is dynamically typed, we cannot compute a FQN for every reference statically. Some references will only be known at runtime. For example:
```python
def fn_factory():
if condition:
return foo
else:
return bar
ambiguous_fn = fn_factory()
ambiguous_fn()
```
We don't know if `foo` or `bar` is referenced in this last line, since we don't know the value of `condition` until the code executes. It follows that it's impossible to parse Python files with perfect accuracy, and therefore impossible to construct a perfect knowledge graph. We must settle for a "good enough" approximation.
As work on the parser progresses, known limitations of the parser will be listed [here.](https://gitlab.com/gitlab-org/rust/gitlab-code-parser/-/issues/36)
epic