Skip to content
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.

Sign up for GitHub

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

Jump to bottom

PEP 682: Discussions-To and minor fixes #2317

Merged
merged 4 commits into from
Feb 11, 2022
Merged

PEP 682: Discussions-To and minor fixes #2317

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
77e1719
fill in Discussions-To
belm0 Feb 9, 2022
6eadf5f
fix future references in Rationale
belm0 Feb 8, 2022
dda7307
Remove "code-block:: pycon", since it applies a proportional
belm0 Feb 8, 2022
2daa445
grammar fix
belm0 Feb 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 13 additions & 23 deletions pep-0682.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,13 @@ PEP: 682
Title: Format Specifier for Signed Zero
Author: John Belmonte <john@neggie.net>
Sponsor: Mark Dickinson <dickinsm@gmail.com>
Discussions-To:
Discussions-To: https://discuss.python.org/t/pep-682-format-specifier-for-signed-zero/13596
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-Jan-2022
Python-Version: 3.11
Post-History:
Post-History: 08-Feb-2022


Abstract
Expand All @@ -27,9 +27,7 @@ zero to be normalized to positive zero.
Motivation
==========

Here is negative zero:

.. code-block:: pycon
Here is negative zero::
Copy link
Contributor Author

Choose a reason for hiding this comment

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

to summarize:

  • the console-specific formatting looks great with the new rendering system for peps.python.org
  • however, rendering on the standard pep site is botched. @AA-Turner notes it may be hard to fix. (I'd be happy to help if it's feasible.)
  • there is only one other PEP so far using pycon
  • it seems we'll need a script to convert console blocks in existing PEP's anyway, so perhaps no need to put this PEP on the bleeding edge

Copy link
Contributor Author

@belm0 belm0 Feb 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

interesting-- the new rendering deduces console blocks anyway

Screen shot after merge of this PR, and confirming other edits are reflected:

Screen Shot 2022-02-11 at 9 28 24 AM

Copy link
Member

Choose a reason for hiding this comment

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

As @AA-Turner explained on the other PR, completely nuking the explict .. code-block declaration is not the correct way to fix this. Instead, you should simply change pycon to python to use the standard Python script file syntax highlighting that doesn't have this problem (which is currently the default, but that is an implementation detail that may change) rather than removing it completely.

it seems we'll need a script to convert console blocks in existing PEP's anyway, so perhaps no need to put this PEP on the bleeding edge

There's not so much benefit to doing so on existing PEPs that would justify the noise, except on Active/Process PEPs as they are updated, so long as we keep the default python, and if not then console blocks are no different than any other non-plain-text code block in that regard.

interesting-- the new rendering deduces console blocks anyway

Indeed—my testing also seems to confirm there is no difference when rendered via the new system, at least for these particular (relatively simple) blocks.


>>> x = -0.
>>> x
Expand All @@ -38,9 +36,7 @@ Here is negative zero:
When formatting a number, negative zero can result from rounding. Assuming
the user's intention is truly to discard precision, the distinction between
negative and positive zero of the rounded result might be considered an
unwanted artifact:

.. code-block:: pycon
unwanted artifact::

>>> for x in (.002, -.001, .060):
... print(f'{x: .1f}')
Expand All @@ -49,18 +45,14 @@ unwanted artifact:
0.1

There are various approaches to clearing the sign of a negative zero. It
can be achieved without a conditional by adding positive zero:

.. code-block:: pycon
can be achieved without a conditional by adding positive zero::

>>> x = -0.
>>> x + 0.
0.0

To normalize negative zero when formatting, it is necessary to perform
a redundant (and error-prone) pre-rounding of the input:

.. code-block:: pycon
a redundant (and error-prone) pre-rounding of the input::

>>> for x in (.002, -.001, .060):
... print(f'{round(x, 1) + 0.: .1f}')
Expand Down Expand Up @@ -112,12 +104,12 @@ one-dimensional numerical arrays would be complicated by such pre-rounding:
"""Format a vector (any iterable) using given per-term format string."""
return f"[{','.join(f'{term:{format_spec}}' for term in v)}]"

To date, there doesn't appear to be other widely-used languages or libraries
providing such a formatting option for negative zero. However, the same
``z`` option syntax and semantics has been `proposed for C++ std::format()`_.
While the proposal was withdrawn for C++20, a consensus proposal is promised
for C++23. (The original `feature request`_ prompting this PEP was argued
without knowledge of the C++ proposal.)
To date, there doesn't appear to be any other widely-used language or library
providing a formatting option for negative zero. However, the same ``z``
option syntax and semantics specified below have been `proposed for C++
std::format()`_. While the proposal was withdrawn for C++20, a consensus
proposal is promised for C++23. (The original `feature request`_ prompting
this PEP was argued without knowledge of the C++ proposal.)

.. _`proposed for C++ std::format()`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1496r2.pdf
.. _`feature request`: https://bugs.python.org/issue45995
Expand All @@ -138,9 +130,7 @@ where ``z`` is allowed for numerical types other than integer. Support for
allowing the specifier to be used in f-strings, built-in ``format()``, and
``str.format()``. The %-formatting style will not support the new option.

Synopsis:

.. code-block:: pycon
Synopsis::

>>> x = -.00001
>>> f'{x:z.1f}'
Expand Down