Use enumerations instead of strings

[ThatXliner]

Instead of using strings to specify an option, we could use enums.

1. It'll make type checking easier (without needing Literal).
2. It will make the API make more sense
3. It'll probably be easier to document (e.g. for future addition)

Since this WILL be a breaking change, it'll definitely be part of API v1

[erezsh]

I think it's a nice idea!

[ThatXliner]

I've started to implement it https://github.com/ThatXliner/lark/tree/patch-3. Kind of?

EDIT: I've started a PR #929

[erezsh]

Hmm, the thing is, I still want to be able to pass strings.

I write stuff like Lark(my_grammar, parser="lalr")

If instead I would have to

from lark.enums import Parser
...
Lark(my_grammar, parser=Parser.LALR)

That would be pretty cumbersome! Especially since I usually pass quite a few parameters..

[erezsh]

Sorry, to clarify, I thought you meant using enums for type signatures.

[ThatXliner]

Hmm, the thing is, I still want to be able to pass strings.

I write stuff like Lark(my_grammar, parser="lalr")

If instead I would have to

from lark.enums import Parser
...
Lark(my_grammar, parser=Parser.LALR)

That would be pretty cumbersome! Especially since I usually pass quite a few parameters..

Good point. Should I allow strings as well? If that's the case, it'll be backwards-compatible. But I think enums are a more elegant choice than trying to verify strings.

If only Python could infer enums like Swift...

[erezsh]

The way I see it, enums make sense --

• for internal code, where you don't constantly sanitize the values, so you want the "type-safety"
• for APIs where you extend a provided object (like Transformer)

But in Lark's case, it's an interface that already gets sanitized. And I believe it would make the use a lot harder.

I agree, if Python could make better use of enums, perhaps they would make a more suitable choice.

[MegaIng]

I don't like the idea:

• We have to do validation in LarkOptions.__init__ anyway, so it doesn't really matter if we have to verify strings or enums.
• It is more cumbersome everywhere we check for the value internally
• Either we force to user to also do more work, or we allow strings as well, in which case we gained nothing for us.
• For type safety with mypy (and in good IDEs, autocomplete) Literal[...] and an Enum are equivalent.
• We can just go the tkinter root and create a few public constants to be used as arguments.

However, if we really want enums, we should at least use str as a mixin and keep the old values.

[ThatXliner]

• We can just go the tkinter root and create a few public constants to be used as arguments.

Works too I guess. The idea is that it's more clear on what the options should be.