LBYL -> EAFP

[CoffeeStraw]

At the moment of writing, a lot of PyonFX's code use LBYL approach ("look before you leap"). This means that a lot of type checking is done and slow down the whole process.

Instead, we should follow EAFP approach ("it’s easier to ask for forgiveness than permission") and the code should be reviewed using try ... except whenever it is possible.

Together with making the code follow the common Python coding style, we should also have a little boost in performance and improve readability.

[Ichunjo]

I personally prefer LBYL but without type checking. That's the reason of typethint. You inform the user of the types to pass and if they don't follow them, that's their fault not ours.

[Ichunjo]

I also feel like EAFP was more pythonic years ago when typehint wasn't a thing but don't quote me about that. Now with mypy and flake8 era, you have to explicitly handle types unless linters will yell at you.
You can still cast type to the value but it begins pretty pepega to do that for everything just because you want to satisfy linters in my opinion

[CoffeeStraw]

Using try ... except we're not really doing type-checking anymore. Instead, we're just clarifying the error(s) to the user.
Following EAFP is what I think it is better for the project: this is a library, so whatever makes final users' life easier (without really no cons) should be done.

For other kinds of projects, I may agree with your opinion.

[CoffeeStraw]

Years have passed, and my opinion on this has definitely shifted. I tend to agree with your philosophy now: code editors have evolved and type hinting has become predominant. The goal of this issue should shift towards making sure type hints are correct in every function (which should be, but a second pass should be needed), and that checks on the input are only present when static type checking is not enough (e.g. expecting a value between 0-255 for rgb).