Skip to content

Commit 27b45b9

Browse files
committed
+ expose imaginary builtin
1 parent bf0d67f commit 27b45b9

1 file changed

Lines changed: 13 additions & 5 deletions

File tree

peps/pep-0812.rst

Lines changed: 13 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -227,9 +227,17 @@ Specification
227227
=============
228228

229229
The :external+py3.14:ref:`imaginary literals <imaginary>` create instances of
230-
imaginary type, all values of this type could be represented as ``x*1j``, where
231-
``x`` is some :external+py3.14:class:`float` number. So, strictly speaking, we
232-
need only one such object, the imaginary unit ``1j``, with a property:
230+
imaginary type:
231+
232+
.. class:: imaginary(x=0.0)
233+
234+
Create an imaginary number from a number or a string.
235+
236+
This is equivalent of ``float(x)*1j``.
237+
238+
239+
Strictly speaking, we need only one such object, the imaginary unit ``1j``,
240+
with a property:
233241

234242
.. code::
235243
@@ -550,8 +558,8 @@ explain then a dedicated concept of imaginary numbers as a subtype of complex.
550558
Open Issues
551559
===========
552560
553-
The PEP doesn't expose a new subtype as a builtin, say ``imaginary``, but maybe
554-
we should? This looks redundant, as all imaginary values could be obtained by
561+
The PEP expose a new subtype as the :class:`imaginary` builtin, but maybe we
562+
shouldn't? This looks redundant, as all imaginary values could be obtained by
555563
scaling the imaginary unit, i.e. ``imaginary(x) == float(x)*1j``.
556564
557565

0 commit comments

Comments
 (0)