Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LBYL -> EAFP #29

Open
CoffeeStraw opened this issue Apr 10, 2021 · 3 comments
Open

LBYL -> EAFP #29

CoffeeStraw opened this issue Apr 10, 2021 · 3 comments

Comments

@CoffeeStraw
Copy link
Owner

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
Copy link
Contributor

Ichunjo commented Jul 30, 2021

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
Copy link
Contributor

Ichunjo commented Jul 30, 2021

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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants