Writing a parser is not that much of work to buy a company in order to do it. Piggybacking on LSP servers and treesitter would be more efficient.

▲

dcreager 3 days ago | parent | next [-]

The parser is not the hard part. The hard part is doing something useful with the parse trees. They even chose "oh is that all?" and a picture of a piece of cake as the teaser image for my Strange Loop talk on this subject!

https://www.youtube.com/watch?v=l2R1PTGcwrE

▲

everforward 3 days ago | parent | prev [-]

Writing a literal parser isn’t too hard (and there’s presumably an existing one in the source code for the language).

Writing something that understands all the methods that come in a Django model goes way beyond parsing the code, and is a genuine struggle in language where you can’t execute the code without worrying about side effects like Python.

Ty should give them a base for that where the model is able to see things that aren’t literally in the code and aren’t in the training data (eg an internal version of something like SQLAlchemy).

▲

skydhash 3 days ago | parent [-]

If you’re talking about magic methods/properties enabled by reflection and macros, then you’re no longer statically analyzing the code.

	▲	everforward 2 days ago \| parent [-]
		Static analysis just requires that you don't actually execute the code. It's possible (sometimes) to infer what methods/properties would be create without actually statically analyzing the code. E.g. mypy has a plugin to read the methods and return types of SQLAlchemy records, I believe without actually executing them. Obviously not globally true, but in limited domains/scenarios you can see what would exist without actually executing the code.