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

Annotate return types for better IDE code completion. #49

Open
hhslepicka opened this issue Apr 3, 2024 · 3 comments
Open

Annotate return types for better IDE code completion. #49

hhslepicka opened this issue Apr 3, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@hhslepicka
Copy link
Collaborator

What's the problem this feature will solve?
Adding the return types will make IDEs better provide users with autocomplete for methods and code in general.

Describe the solution you'd like
Types to be annotated where possible.

Additional context
Motivated by forum post https://community.botcity.dev/t/function-menu-select-error/646/2

@hhslepicka hhslepicka added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Apr 3, 2024
@welli7ngton
Copy link
Contributor

Hi there!

I'm currently working on this issue, and I wanted to get your thoughts before diving deeper.

Questions:
- Do you think annotating the entire bot.py file on the first attempt is too ambitious?
My concern is that it might be overwhelming without a clear strategy.
- Would creating interfaces for the classes in this file be a good idea?
I’m considering this to improve modularity and clarity.

If you have any advice or suggestions on where to start, I'd appreciate to hear them!

@hhslepicka
Copy link
Collaborator Author

@welli7ngton thank you for working on this issue.

As far as your questions:

  • That would be great! As far as splitting the work to make it more manageable I would suggest maybe following the division we have in our documentation portal. This way we can review and merge your changes faster.
  • No, please don't add interfaces for the classes. This is not a good idea for this particular case.

When contributing please make sure to:

  • Use a feature/bug branch
  • Use clear commit messages

Let me know if you have questions!
Feel free to join our Community Slack and send me and the team a message there if you prefer.

@welli7ngton
Copy link
Contributor

Should we keep matching and grayscale optional?

annotation

  • attention to grayscale and matching

warning

what do you guys think about removing the optional annotation to just float, I got this warning when I try to call the cv2.locate_all_open_cv function

I asked because in the documentation there is a field saying that the argument must also be optional, before my changes the arguments were just name=default_value.

image

@hhslepicka

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants