classification
Title: Document default numeric string formats
Type: Stage: resolved
Components: Documentation Versions: Python 3.10, Python 3.9, Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, eric.araujo, eric.smith, kop, miss-islington
Priority: normal Keywords: patch

Created on 2020-01-22 02:35 by kop, last changed 2020-12-16 03:18 by eric.araujo. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 18111 merged kop, 2020-01-22 02:41
PR 22860 merged miss-islington, 2020-10-21 17:14
PR 22861 merged miss-islington, 2020-10-21 17:14
PR 22867 merged kop, 2020-10-21 20:16
PR 22868 merged miss-islington, 2020-10-21 20:34
PR 22869 merged miss-islington, 2020-10-21 20:34
Messages (10)
msg360442 - (view) Author: Karl O. Pinc (kop) * Date: 2020-01-22 02:35
Seems sane to put _some_ restrictions on the string representations of the Numeric classes.  This would be a change to the Python language
specification.

Suggestions made in a pull request.

See the email thread:
Subject: Documenting Python's float.__str__()
https://mail.python.org/archives/list/python-dev@python.org/thread/FV22TKT3S2Q3P7PNN6MCXI6IX3HRRNAL/
msg360449 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-01-22 06:09
Is the lack of this documentation causing some confusion somewhere? This isn't rhetorical, I'm genuinely curious what problem you're trying to solve.

Is there any mainstream programming language where the basics of what you've laid out aren't true? It all seems pretty obvious to me. For example, I can't see anyone looking at this and saying "Ah, base 10. That's why it's producing the output I'm seeing."
msg360465 - (view) Author: Karl O. Pinc (kop) * Date: 2020-01-22 13:20
On Wed, 22 Jan 2020 06:09:41 +0000
"Eric V. Smith" <report@bugs.python.org> wrote:

> Eric V. Smith <eric@trueblade.com> added the comment:
> 
> Is the lack of this documentation causing some confusion somewhere?
> This isn't rhetorical, I'm genuinely curious what problem you're
> trying to solve.

I'd say no, there's no real confusion anywhere.

This started with a search for documentation on Python's
default string representation for float.  This accidentally
wound up on the python-dev mailing list and became a
more general discussion during which I suggested that
some fundamentals are clear.  This is pretty much just
a follow-up to that discussion.

> Is there any mainstream programming language where the basics of what
> you've laid out aren't true? It all seems pretty obvious to me. For
> example, I can't see anyone looking at this and saying "Ah, base 10.
> That's why it's producing the output I'm seeing."

Well, I just got done looking at YAML which has a lot of base-related
syntax including base 60.  :)

The problem that would be solved is that it's easy to rely
on the default Numeric output formats.  Most output probably
does not go through a formatter, although this may change
now that f-strings are so easy.  Anyway, this would guarantee
"normal output" for numbers, even when switching between
Python implementations.

Likewise, immutability of value when round-tripping through a
string is also obvious.  But is still an important property.

So if these properties are important then include them in the spec.
That's what specs are for.  (I could probably find some non-mainstream
languages (scheme perhaps) that have specs which include
similar documentation.  You pretty have to have a formatter
in compiled languages, so those won't specify a default.
Anyway, it shouldn't matter what other language specs do.)

I understand if nobody sees this as a real problem.  And
I don't want to stand up as a big proponent.  I'll
point out the argument here and let others decide.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein
msg379224 - (view) Author: miss-islington (miss-islington) Date: 2020-10-21 17:13
New changeset c60394c7fc9cc09b16e9675a3eeb5844b6d8523f by kpinc in branch 'master':
bpo-39416: Document some restrictions on the default string representations of numeric classes (GH-18111)
https://github.com/python/cpython/commit/c60394c7fc9cc09b16e9675a3eeb5844b6d8523f
msg379232 - (view) Author: miss-islington (miss-islington) Date: 2020-10-21 18:56
New changeset ec62b47ebc8f29007942c8e9f3f260af91ca58cb by Miss Skeleton (bot) in branch '3.9':
[3.9] bpo-39416: Document some restrictions on the default string representations of numeric classes (GH-18111) (GH-22860)
https://github.com/python/cpython/commit/ec62b47ebc8f29007942c8e9f3f260af91ca58cb
msg379233 - (view) Author: miss-islington (miss-islington) Date: 2020-10-21 18:56
New changeset 89fac4c3748aa7eb23d09922331e90a62ce782fd by Miss Skeleton (bot) in branch '3.8':
[3.8] bpo-39416: Document some restrictions on the default string representations of numeric classes (GH-18111) (GH-22861)
https://github.com/python/cpython/commit/89fac4c3748aa7eb23d09922331e90a62ce782fd
msg379234 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2020-10-21 18:57
Thanks for the patch!
msg379249 - (view) Author: miss-islington (miss-islington) Date: 2020-10-21 20:34
New changeset f8b1ccd63c94bcde1c15d56d24add89861b6ceee by kpinc in branch 'master':
Fix bpo-39416: Change "Numeric" to lower case; an english word, not a class name (GH-22867)
https://github.com/python/cpython/commit/f8b1ccd63c94bcde1c15d56d24add89861b6ceee
msg379252 - (view) Author: miss-islington (miss-islington) Date: 2020-10-21 20:54
New changeset 224ed378b9aadad9dbbd890064677433188aecd9 by Miss Skeleton (bot) in branch '3.9':
Fix bpo-39416: Change "Numeric" to lower case; an english word, not a class name (GH-22867)
https://github.com/python/cpython/commit/224ed378b9aadad9dbbd890064677433188aecd9
msg383115 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2020-12-16 03:18
New changeset aedc94b8e9d0f7700c665d8d1ba9c93df33e63a8 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39416: change word case to not imply ABC (GH-22867) (GH-22869)
https://github.com/python/cpython/commit/aedc94b8e9d0f7700c665d8d1ba9c93df33e63a8
History
Date User Action Args
2020-12-16 03:18:24eric.araujosetmessages: + msg383115
2020-10-21 20:54:43miss-islingtonsetmessages: + msg379252
2020-10-21 20:34:39miss-islingtonsetpull_requests: + pull_request21811
2020-10-21 20:34:31miss-islingtonsetpull_requests: + pull_request21810
2020-10-21 20:34:23miss-islingtonsetmessages: + msg379249
2020-10-21 20:16:14kopsetpull_requests: + pull_request21809
2020-10-21 18:57:12eric.araujosetstatus: open -> closed

versions: + Python 3.8, Python 3.9, Python 3.10
nosy: + eric.araujo

messages: + msg379234
resolution: fixed
stage: patch review -> resolved
2020-10-21 18:56:25miss-islingtonsetmessages: + msg379233
2020-10-21 18:56:24miss-islingtonsetmessages: + msg379232
2020-10-21 17:14:27miss-islingtonsetpull_requests: + pull_request21803
2020-10-21 17:14:16miss-islingtonsetpull_requests: + pull_request21802
2020-10-21 17:13:54miss-islingtonsetnosy: + miss-islington
messages: + msg379224
2020-01-22 13:20:31kopsetmessages: + msg360465
2020-01-22 06:09:41eric.smithsetnosy: + eric.smith
messages: + msg360449
2020-01-22 02:42:00kopsetkeywords: + patch
stage: patch review
pull_requests: + pull_request17498
2020-01-22 02:35:29kopcreate