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

Better filter and documentation for qmk find #23711

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Snipeye
Copy link
Contributor

@Snipeye Snipeye commented May 13, 2024

Description

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Copy link
Contributor

@elpekenin elpekenin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic looks good to me, some feedback on code style.

@@ -11,7 +11,7 @@
action='append',
default=[],
help= # noqa: `format-python` and `pytest` don't agree here.
f"Filter the list of keyboards based on their info.json data. Accepts the formats key=value, function(key), or function(key,value), eg. 'features.rgblight=true'. Valid functions are {filter_help()}. May be passed multiple times; all filters need to match. Value may include wildcards such as '*' and '?'." # noqa: `format-python` and `pytest` don't agree here.
f"Filter the list of keyboards based on their info.json data. Accepts the formats key=value, function(key), or function(key,value), eg. 'features.rgblight=true' or 'length(encoder.rotary, >=20)'. Valid functions are {filter_help()}. May be passed multiple times; all filters need to match. Value may include wildcards such as '*' and '?'." # noqa: `format-python` and `pytest` don't agree here.
Copy link
Contributor

@elpekenin elpekenin May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont like the special handling here. Imo everything should come from filter_help and be self-contained on the classes

Could implement a get_help() function on the base class, as simply returning the function's name by default, and overwrite when needed. Then, for the sake of readability, print them as (instead of the current single-line approach)

* One function
* Another function
    Extra docs

Where the indentation is handled by the class adding a long description and the "common" code looks like
"\n * ".join(klass.get_help() for klass in FilterFunction.__subclasses__())

@@ -61,10 +61,22 @@ def apply(self, target_info: TargetInfo) -> bool:

class Length(FilterFunction):
func_name = "length"
funcMap = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a nitpick, camelCase looks off when everything else is snake_case... Its the "official" format for vars anyway.


def apply(self, target_info: TargetInfo) -> bool:
_kb, _km, info = target_info
return (self.key in info and len(info[self.key]) == int(self.value))
val = int(''.join(c for c in self.value if c.isdigit()))
Copy link
Contributor

@elpekenin elpekenin May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as i can tell this is intended to convert the (potentially) {<,<=,>,>=}number into an actual int, but i dont like it because of two things:

  • You will mistakenly (and silently) convert weird inputs into numbers, eg: 3a2 or 3.2 will be parsed as 32
  • Is (IMO) much less readable than just doing
for start, func in self.funcMap: # i would also name this something like "operator"
    if self.value.startswith(start):
        comp = func
        val = int(self.value[len(start):]  # remove prefix, then convert to int (or fail trying to do so)

Also, the extra parenthesis on the for, if and return look a bit off, but just code style yet again

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

Successfully merging this pull request may close these issues.

None yet

3 participants