Port type verification#425
Conversation
Codecov Report
@@ Coverage Diff @@
## master #425 +/- ##
==========================================
- Coverage 58.56% 54.26% -4.30%
==========================================
Files 72 80 +8
Lines 2756 3282 +526
==========================================
+ Hits 1614 1781 +167
- Misses 1142 1501 +359
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
This PR address the related issue #338 When using PMA sensors, checks that the user has entered a valid port - both a sensible value like D0, and also that the port type is valid for the particular sensor being used. |
| if port_name not in Port.keys(): | ||
| raise ValueError(f"{port_name} is not a valid port name. An example of a valid port name is D0") | ||
|
|
||
| if not port_name.startswith("D"): | ||
| raise ValueError(f"{port_name} is not a valid port type for a button. Try using a digital port, such as D0") | ||
|
|
There was a problem hiding this comment.
I think that this should be handled by a mixin (see Stateful, Recreatable...) so that it doesn't need to be duplicated. Not sure what I'd call it though...
There was a problem hiding this comment.
Yeah I was thinking the same, I'd just call it "AnalogComponent" or "DigitalComponent". I wouldn't necessarily call it a "mixin" though, it's just standard inheritance (Button is a DigitalComponent). Admittedly the name DigitalComponent does kind of suggest it does more than just port checking, so maybe "mixin" is the right terminology and it should be called DigitalPortValidator 😃
There was a problem hiding this comment.
Actually, Button inherits from gpiozero's Button class. It uses Stateful and Recreatable mixins (which are included, not inherited) - the same would be the case for this?
There was a problem hiding this comment.
Well yeah but it's still inheritance - the only difference between a mixin and inheritance is generally just if the parent can't be used standalone it's called a "mixin". But then that definition doesn't really apply to abstract base classes, which is still inherited and definitely can't be used standalone. Anyway this is just terminology at this point, I think the idea makes sense
|
This pull request introduces 2 alerts when merging 43c9fcd into 4b4d30d - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 69fffe2 into 4b4d30d - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging cdbdeb3 into 4b4d30d - view on LGTM.com new alerts:
|
| from time import sleep | ||
|
|
||
| button = Button("D5") | ||
| button = Button("D8") |
There was a problem hiding this comment.
I don't think this is relevant..?
| def __init__(self, port_name): | ||
| self.port_name = port_name | ||
|
|
||
| if port_name not in valid_digital_ports: |
There was a problem hiding this comment.
I think I would prefer to see regex used here to match ports: D[0-7]
|
|
||
| def __init__(self, port_name, pin_number=1, name="adcbase"): | ||
| if port_name not in Port.keys(): | ||
| raise ValueError(f"{port_name} is not a valid port name. An example of a valid port name is A0") |
There was a problem hiding this comment.
It's usually better to create a new Exception class specific for things like this, but we don't really have much in the way of uniform exception handling. Perhaps this should be created as a new Issue for across the SDK rather than tackling that here.
| self.name = name | ||
|
|
||
| if port_name not in Port.keys(): | ||
| raise ValueError(f"{port_name} is not a valid port name. An example of a valid port name is D0 or A1") |
There was a problem hiding this comment.
Same thing here re: regex and exceptions.
Now uses regex instead of dictionary list, as per Mike's suggestion. Needs proper testing though.
for more information, see https://pre-commit.ci
|
This pull request introduces 5 alerts when merging 32e3dc8 into dda2052 - view on LGTM.com new alerts:
|
|
This pull request introduces 3 alerts when merging 5f1cd5b into dda2052 - view on LGTM.com new alerts:
|
|
@m-roberts I think this one's ready to be merged. I took into account your comments and used regex instead of dictionaries. Have tested it, and it's passed those automatic checks too. Do I just tag you here to request for it to be merged? |
|
This pull request introduces 3 alerts when merging 56d182b into a7614ea - view on LGTM.com new alerts:
|
Closes #338