daq.begin keyboard interrupt handling is disruptive
Open
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 9
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 1
Description
Current Behavior
daq.begin has a KeyboardInterrupt try/except block that can be disruptive if trying to use daq.begin in a loop. It also looks like it could be bad if someone does ctrl+c right at the instant we start the begin.
Consider changing behavior with the goals:
- do not catch an interrupt if called from trigger, kickoff, etc.
- do catch an interrupt if running interactively
- reraise the interrupt? or not? Open question
- a request has come in for
daq.beginto return whether it succeeded or not
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the daq.begin entry point and trace how it is called from trigger and kickoff versus interactive use. Clarify when KeyboardInterrupt should be caught or re-raised and whether begin should report success. Done means the behavior is decided and covered for looped, interactive, and interrupt-at-start scenarios.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100