Skip to content

gh-146436: Implementation of PEP 786#146437

Draft
jb2170 wants to merge 8 commits into
python:mainfrom
jb2170:pep-786
Draft

gh-146436: Implementation of PEP 786#146437
jb2170 wants to merge 8 commits into
python:mainfrom
jb2170:pep-786

Conversation

@jb2170

@jb2170 jb2170 commented Mar 25, 2026

Copy link
Copy Markdown
Contributor

@jb2170

jb2170 commented Mar 25, 2026

Copy link
Copy Markdown
Contributor Author

I managed to achieve the implementation of precision without having to cannibalize the internals of _PyLong_Format, or (calc_number_widths, fill_number, NumberFieldWidths) in formatter_unicode.c, that's nice.

@vstinner

Copy link
Copy Markdown
Member

Note for myself: "PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields" is still a draft: python/peps#4416.

@picnixz

picnixz commented Mar 25, 2026

Copy link
Copy Markdown
Member

Can we avoid creating reference implementations on the main repo please? use a fork please. In addition, issues should be created once it's been discussed and accepted, not before.

@jb2170

jb2170 commented Mar 25, 2026

Copy link
Copy Markdown
Contributor Author

I already thought of setting the PEP reference implementation link to a branch on my fork, but then I realized that the upstream python/cpython repo serves as a better permalink; that branch on my fork might get deleted once merged!

@picnixz

picnixz commented Mar 25, 2026

Copy link
Copy Markdown
Member

In this case, you can create your own repository. We usually avoid creating PRs for features that are still under discussions.

@skirpichev

Copy link
Copy Markdown
Member

that branch on my fork might get deleted once merged!

You can create a pr in your fork and point to that, not to the branch. Then (unless you delete the fork) - you can re-create removed branches. And people still be able to see your patch even if the branch itself will be deleted. See e.g.: skirpichev#1

Though, as this pr was already opened - lets keep this work here (as a draft).

@jb2170

jb2170 commented Mar 26, 2026

Copy link
Copy Markdown
Contributor Author

We usually avoid creating PRs for features that are still under discussions.

Though, as this pr was already opened - lets keep this work here (as a draft).

I'll remember that for the future! 😅
I made sure to make this a draft PR for now

Rebased successfully with no conflicts, pushing now

I do wish the developers guide (documentation section) would say to
`make -C Doc/ check` to avoid the embarassment of pushing broken docs.
I tracked down the failing test to a 'sphinx-lint' in
`.pre-commit-config.yaml` but how that links up to the 'check' target in
Docs/Makefile isn't clear.
@github-actions

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DO-NOT-MERGE stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants