Add v0.4 re-implementation plan#11
Conversation
Covers the remaining work from PR #10 that will be re-implemented from scratch: type system simplification, documentation rewrites, benchmarking suite, and housekeeping.
📝 WalkthroughWalkthroughA new planning document Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/v0.4-plan.md`:
- Line 124: Update the stale license year string "2025" to the current year
"2026" in the docs content (the line containing "License year → 2025"); search
for any other occurrences of the same "License year" token in this document and
replace them as well to keep license metadata consistent.
- Around line 13-16: The spec's 1-byte length prefix for bytes[N], string[N],
and T[N] is ambiguous for capacities >255; update the grammar to either
explicitly constrain the capacity by adding "N <= 255" to the definitions of
bytes[N], string[N], and T[N], or replace the 1-byte prefix with a
wider/variable-length length-field (e.g., 2-byte fixed width or a varint) and
describe its encoding (endianness/varint scheme) and max representable length so
the wire format no longer silently truncates or misinterprets lengths above 255.
- Line 74: The docs currently propose bumping the minimum Python to 3.13 without
evidence; either remove that change and keep Python 3.8+ everywhere or provide
concrete code/stdlib/features that require 3.13 and update the configuration
accordingly: if keeping 3.13+, update the version specifier in pyproject.toml
(the python requirement under [tool.poetry.dependencies] or equivalent), update
the docs line in the v0.4 plan that reads "Update version requirement to Python
3.13+", and adjust the CI test matrix entries to include only 3.13+; otherwise
revert the docs change and ensure CI and pyproject.toml continue to test and
allow 3.8+.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| - `bytes[N]` — 1-byte length prefix + up to N bytes | ||
| - `string[N]` — null-terminated, up to N chars (no padding) | ||
| - `T[N]` — 1-byte length prefix + up to N elements | ||
|
|
There was a problem hiding this comment.
Define behavior for capacities above 255 in the new wire format.
Using a fixed 1-byte length prefix conflicts with unconstrained N. Please explicitly constrain N <= 255 in grammar/spec, or switch to a wider/variable-length prefix to avoid silent truncation/format ambiguity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/v0.4-plan.md` around lines 13 - 16, The spec's 1-byte length prefix for
bytes[N], string[N], and T[N] is ambiguous for capacities >255; update the
grammar to either explicitly constrain the capacity by adding "N <= 255" to the
definitions of bytes[N], string[N], and T[N], or replace the 1-byte prefix with
a wider/variable-length length-field (e.g., 2-byte fixed width or a varint) and
describe its encoding (endianness/varint scheme) and max representable length so
the wire format no longer silently truncates or misinterprets lengths above 255.
|
|
||
| - Add async examples using `messages()` iterator | ||
| - Document `async_=True` parameter | ||
| - Update version requirement to Python 3.13+ |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What Python language/runtime features introduced in Python 3.13 would justify setting a project minimum version to 3.13+, and what are common compatibility tradeoffs for CLI/library projects?
💡 Result:
Key Python 3.13 features justifying a minimum version of 3.13+ for projects include an improved interactive interpreter (REPL) with multi-line editing, colorized tracebacks by default, experimental free-threaded mode (no-GIL, PEP 703) for better multi-threading performance in CPU-bound tasks, an experimental JIT compiler (PEP 744) for potential speedups, defined semantics for locals mutations (PEP 667), typing improvements like default type parameters (PEP 696), and removal of 19 dead battery stdlib modules (PEP 594) plus lib2to3. For CLI/library projects, common compatibility tradeoffs are minimal for pure Python code: most changes are additive or opt-in. However, projects using removed modules (e.g., cgi, pipes, telnetlib, audioop) must migrate to alternatives like shlex for pipes or third-party libs. C extensions need checking for free-threading compatibility if using that mode (via Py_mod_gil slot); standard builds are backward-compatible. Some third-party libs had initial issues (e.g., docstring handling, argparse output changes, removed module deps like pipes in python-fire), but most popular packages now support 3.13. Test thoroughly, especially REPL-dependent CLIs benefit greatly. Longer support (2 years bugfixes + 3 years security) vs older versions aids maintenance.
Citations:
- 1: https://docs.python.org/3/whatsnew/3.13.html
- 2: https://docs.python.org/3.13/whatsnew/index.html
- 3: https://github.com/python/cpython/blob/1b118353/Doc/whatsnew/3.13.rst
- 4: https://thinhdanggroup.github.io/python313-upgrade-guide/
- 5: https://github.com/python/cpython/blob/main/Doc/deprecations/pending-removal-in-3.13.rst
- 6: https://docs.python.org/3.13/library/removed.html
- 7: cli: Fix docstring processing with Python 3.13+ tqdm/tqdm#1594
- 8: Python 3.13 experimental support? google/python-fire#570
🏁 Script executed:
# Find project metadata files to understand current Python requirements
git ls-files | grep -E "(pyproject\.toml|setup\.py|setup\.cfg|tox\.ini|.github)" | head -20Repository: emmapowers/bakelite
Length of output: 133
🏁 Script executed:
# Look at the v0.4-plan.md file to understand context
head -100 docs/v0.4-plan.md | tail -50Repository: emmapowers/bakelite
Length of output: 1657
🏁 Script executed:
# Search for any Python version constraints in project files
fd -e toml -e py -e cfg -e ini | xargs grep -l "python" 2>/dev/null | head -10Repository: emmapowers/bakelite
Length of output: 262
🏁 Script executed:
cat pyproject.tomlRepository: emmapowers/bakelite
Length of output: 2155
🏁 Script executed:
cat .github/workflows/test.yamlRepository: emmapowers/bakelite
Length of output: 686
🏁 Script executed:
cat .github/workflows/lint.yamlRepository: emmapowers/bakelite
Length of output: 621
🏁 Script executed:
# Search for any Python version-specific imports or features
rg "sys\.version|python_requires|TaskGroup|override|PEP 6[67][0-9]" --type pyRepository: emmapowers/bakelite
Length of output: 45
🏁 Script executed:
# Check dependencies for Python version requirements
grep -A 20 "tool.poetry.dependencies" pyproject.toml | grep -E "python|click|jinja|lark|dataclasses"Repository: emmapowers/bakelite
Length of output: 154
🏁 Script executed:
# Check if there's broader context in v0.4-plan.md about the version bump
cat docs/v0.4-plan.md | grep -B5 -A5 "3.13"Repository: emmapowers/bakelite
Length of output: 352
🏁 Script executed:
# Search codebase for async usage that might benefit from 3.13
rg "async|await|asyncio" --type py | head -20Repository: emmapowers/bakelite
Length of output: 45
🏁 Script executed:
# Check if git history shows any 3.13-related discussions
git log --oneline -20 2>/dev/null | head -20Repository: emmapowers/bakelite
Length of output: 102
Confirm or reject Python 3.13+ floor—no concrete features justify this break.
Current code targets Python 3.8+ with no dependencies requiring 3.13+. No async/await usage, removed stdlib modules, or runtime features in the codebase justify requiring 3.13+. Proposed async examples in v0.4 do not depend on Python 3.13 (async available since 3.4). Before committing this as policy in docs, either identify concrete features requiring 3.13+ and update pyproject.toml and CI test matrix accordingly, or retain 3.8+ compatibility.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/v0.4-plan.md` at line 74, The docs currently propose bumping the minimum
Python to 3.13 without evidence; either remove that change and keep Python 3.8+
everywhere or provide concrete code/stdlib/features that require 3.13 and update
the configuration accordingly: if keeping 3.13+, update the version specifier in
pyproject.toml (the python requirement under [tool.poetry.dependencies] or
equivalent), update the docs line in the v0.4 plan that reads "Update version
requirement to Python 3.13+", and adjust the CI test matrix entries to include
only 3.13+; otherwise revert the docs change and ensure CI and pyproject.toml
continue to test and allow 3.8+.
| ## 4. Copyright / housekeeping | ||
|
|
||
| Already handled in PR #7. If anything was missed: | ||
| - License year → 2025 |
There was a problem hiding this comment.
Update the housekeeping year to the current year.
Line 124 says 2025, but today is April 14, 2026; this should be updated to avoid stale license metadata guidance.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/v0.4-plan.md` at line 124, Update the stale license year string "2025"
to the current year "2026" in the docs content (the line containing "License
year → 2025"); search for any other occurrences of the same "License year" token
in this document and replace them as well to keep license metadata consistent.
1 participant
Summary
docs/v0.4-plan.mdcovering the remaining work to be re-implemented from scratch after the modernization PR chain landsContext
PR #10 was too large to merge as-is. This is PR #0 of a stacked chain that breaks it into reviewable pieces. Items that are too cross-cutting to cherry-pick cleanly (type system change, benchmarks) are documented here for re-implementation.
Test plan
Summary by CodeRabbit