📚 `ubquery.py` says `eval` resolves names eagerly; measured, it short-circuits exactly like the fast path
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 82/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- documentation
Research direction
The wrong claim sits in the module docstring at packages/sphinx-needs/src/sphinx_needs/ubquery.py lines 7-14. Before editing, run the two eval snippets quoted in the issue in a Python 3.13 shell to confirm the short-circuit and NameError behaviour. Done means the docstring gives cost, not short-circuit semantics, as the reason the fast path exists, and no longer says eval resolves names eagerly.
Written by the indexing model from the issue text.
Description
The module docstring of packages/sphinx-needs/src/sphinx_needs/ubquery.py:7-14 says that per-type fields are "not possible with eval() since it eagerly evaluates all names in the expression context upfront", as the reason the fast path resolves names lazily.
Measured at master 3210ac5c (2026-10-14, CPython 3.13): eval('type == "nope" and absent_field == "x"', ctx) returns False with no error, and eval('absent_field == "x"', ctx) raises NameError. Python's eval resolves names lazily and short-circuits and/or exactly as ubquery does. What is eager on the eval path is building the context (every key materialised by filter_context()), not the name lookup — and that is where the eval path's cost is (13.9 of 14.0 ms per 10 000 needs for status == "open").
Fix the docstring: the fast path's advantage is cost (no context dict per need), not short-circuit semantics; a type-guarded expression over an absent field works on both paths.
- Dominant language
- Python
- Stars
- 309
- Forks
- 103
- Avg merge
- 11h 26m
- Merged PRs (30d)
- 118
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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.
More from useblocks/sphinx-needs
-
bug pkg: sphinx-needs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
useblocks/sphinx-needs#2253 ·
Maintainers usually reply within 1 day
-
bug pkg: sphinx-needs
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
useblocks/sphinx-needs#2251 ·
Maintainers usually reply within 1 day
-
bug pkg: sphinx-needs
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
useblocks/sphinx-needs#2249 ·
Maintainers usually reply within 1 day
-
documentation pkg: sphinx-test-reports
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
useblocks/sphinx-needs#2247 ·
Maintainers usually reply within 1 day
-
documentation pkg: workspace
Difficulty 1/5 Under an hour Newbie friendliness 82/100
useblocks/sphinx-needs#2236 ·
Maintainers usually reply within 1 day
All issues in useblocks/sphinx-needs
Similar issues
-
`burr` fails to start when the Python path has a space in itPossibly taken @enekoreto claimed this today. Openstatus/needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 5 days
-
gemini 出现了新的域名需要加入Open
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 2/5 Half a day Newbie friendliness 72/100
debpalash/VoiceStudio#2903 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dagster-io/community-integrations#367 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
aws-samples/sample-per-model-bedrock#243 ·
Maintainers usually reply within 1 day