MegaIng

Well, yes for those simple situations lark isn't that good. If you can just use a single regex, use it. I recently started work on a implementation in nim, instantly...

Is someone working on this right now? Otherwise I will give it a try.

Note that this is something that might break compatibility. This is something we have in mind, and I think we also agree that it would be better for both parser...

Well, yes, `\n` is part of the regex group `\s`. This is not a 'problem' of lark, but of the re library.

I think @erezsh made a mistake, but I am not sure.

Can you provided an example grammar(s)? lark should not do more than one import of `common.lark` per grammar file.

> wouldn't it be better to cache the grammar once and for all? Parsing/loading the grammar file is almost certainly not the problem. Also, consider these grammars: ``` // common_rules...

> or am i completely mistaken in thinking what's slowing down the construction of the parser is the opening and closing of the files (we're talking literally 100+ openings of...

@ornariece I would expect that whole operation to be the fast part and the slow part to come afterwards (when compiling the grammar).

@ornariece Can you check if the loading part is the slow stuff by adding ``` from functools import lru_cache import pkgutil pkgutil.get_data = lru_cache(pkgutil.get_data) ``` before import lark? (This should...