Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

PEP 812: Imaginary type and IEC 60559-compatible complex arithmetic #4681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
skirpichev wants to merge 29 commits into python:main
base: main
Choose a base branch
Loading
from skirpichev:imaginary

Conversation

@skirpichev
Copy link
Contributor

@skirpichev skirpichev commented Oct 31, 2025 •
edited
Loading

Basic requirements (all PEP Types)

  • Read and followed PEP 1 & PEP 12
  • File created from the latest PEP template
  • PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
  • Title clearly, accurately and concisely describes the content in 79 characters or less
  • Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
  • Author, Status (Draft), Type and Created headers filled out correctly
  • (削除) PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate (削除ここまで)
  • Required sections included
    • Abstract (first section)
    • Copyright (last section; exact wording from template required)
  • Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
  • PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
  • Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

  • PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
  • Suggested sections included (unless not applicable)
    • Motivation
    • Rationale
    • Specification
    • Backwards Compatibility
    • (削除) Security Implications (削除ここまで)
    • How to Teach This
    • Reference Implementation
    • Rejected Ideas
    • Open Issues
  • Python-Version set to valid (pre-beta) future Python version, if relevant
  • (削除) Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such (削除ここまで)
  • Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

📚 Documentation preview 📚: https://pep-previews--4681.org.readthedocs.build/

https://pep-previews--4681.org.readthedocs.build/pep-0812/

serhiy-storchaka and dg-pb reacted with thumbs up emoji
@hugovk hugovk changed the title (削除) PEP 812: Imaginary type and IEC 60559-compatible complex arithmetic (削除ここまで) (追記) PEP 9999: Imaginary type and IEC 60559-compatible complex arithmetic (追記ここまで) Oct 31, 2025
Copy link
Contributor Author

skirpichev commented Oct 31, 2025 •
edited
Loading

Based on feedback from the latest discussion thread, I hope @serhiy-storchaka might sponsor this.

CC @serhiy-storchaka
CC @mdickinson

(Alternative formatting with mathjax)

N.B. I did local builds with the default sphinx config and it seems, that "math" directives are rendered odd with the "maths_to_html". In particular, equation numbering is lost (though, references to equations are kept). Any way to fixing this without replacing "math" with something else? CC @AA-Turner
Locally I've something like this:
Screenshot from 2025年10月31日 09-18-03

@skirpichev skirpichev added the new-pep A new draft PEP submitted for initial review label Oct 31, 2025
Copy link
Member

hugovk commented Oct 31, 2025

Please review PEP 1.

The general order of things:

  1. Open a discussion to see if there is consensus for this idea. This is also to save you time in case the idea is rejected.
  2. During the discussion, find a sponsor.
  3. Work with your sponsor, and when they think the PEP is ready for submission, then open the PR.
  4. A PEP number is assigned by a PEP editor after the sponsor has confirmed their sponsorship.

Therefore please don't write and submit a PEP with just a hope someone will sponsor. This should be arranged beforehand.

This comment was marked as outdated.

This comment was marked as resolved.

This comment was marked as resolved.

@skirpichev skirpichev marked this pull request as ready for review November 1, 2025 03:00
@skirpichev skirpichev requested a review from a team as a code owner November 1, 2025 03:00
Copy link
Member

hugovk commented Nov 1, 2025

@hugovk, may I reserve some number and set CODEOWNERS?

Yes, you may use 812. Thanks!
skirpichev reacted with thumbs up emoji

@hugovk hugovk changed the title (削除) PEP 9999: Imaginary type and IEC 60559-compatible complex arithmetic (削除ここまで) (追記) PEP 812: Imaginary type and IEC 60559-compatible complex arithmetic (追記ここまで) Nov 1, 2025
Copy link
Member

@hugovk hugovk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly grammar nits.

Copy link
Contributor Author

skirpichev commented Nov 6, 2025 •
edited
Loading

@serhiy-storchaka, I hope now this ready for your review.

(削除) Perhaps, the major remaining question is: should we try to introduce the imaginary builtin from beginning? Current version don't do so (it's in Open Issues), but maybe this should be reverted? If we introduce a new builtin - this PEP can discuss parsing of strings, which it will accept. (削除ここまで)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@hugovk hugovk Awaiting requested review from hugovk

@serhiy-storchaka serhiy-storchaka Awaiting requested review from serhiy-storchaka

Assignees

No one assigned

Labels

new-pep A new draft PEP submitted for initial review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /