Skip to content

PEP 682: Discussions-To and minor fixes #2317

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

Merged
JelleZijlstra merged 4 commits into from
Feb 11, 2022
Merged

PEP 682: Discussions-To and minor fixes #2317

Changes from 1 commit
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
Prev Previous commit
Next Next commit
Remove "code-block:: pycon", since it applies a proportional 
font to '>>>' and '...', which looks odd and misaligns indents.
  • Loading branch information
@belm0
belm0 committed Feb 9, 2022
commit dda7307d984cfe9ade68a5e06278c0a3bd9d2563
20 changes: 5 additions & 15 deletions pep-0682.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,9 +27,7 @@ zero to be normalized to positive zero.
Motivation
==========

Here is negative zero:

.. code-block:: pycon
Here is negative zero::

@belm0 belm0 Feb 11, 2022

Copy link
Copy Markdown
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

@belm0 belm0 Feb 11, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

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

@CAM-Gerlach CAM-Gerlach Feb 15, 2022

Copy link
Copy Markdown
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 @@ -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