This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: SUGGESTION: New Datatypes
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Devyn Johnson, mark.dickinson
Priority: normal Keywords:

Created on 2015-12-18 12:23 by Devyn Johnson, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg256678 - (view) Author: Devyn Johnson (Devyn Johnson) Date: 2015-12-18 12:23
As we all know, Python is sometimes used to computer large numbers and precise numbers (i.e. doubles) with the help of third-party modules. In my opinion, it seems that Python may benefit from gaining new data-types such as "longint" (a "long long" in C) and "quad" (a "long double" in C). Thus, Python could natively be used for processing larger numbers than Python3.6.
msg256682 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-12-18 14:07
Are you aware that Python's int type is already effectively arbitrary precision?

>>> 23**100
14886191506363039393791556586559754231987119653801368686576988209222433278539331352152390143277346804233476592179447310859520222529876001
>>> type(23**100)
<class 'int'>

For the suggestion of "quad": this has come up a couple of times in the past, but there are many things that would need to be discussed:

- Is it actually useful or necessary?
- Is it useful enough to warrant being included in the standard library, rather than provided by 3rd party libraries (gmpy, mpmath, ...).
- Would it be better to provide an arbitrary-precision binary floating-point type? What would this provide that the existing arbitrary-precision decimal floating-point type (in the decimal module) doesn't already provide.
- What would the impact be on the rest of the core code and the standard library: how many modules would need to be adapted to work with the new floating-point type, and how much work would that be?
- What would the format be? You suggest matching "long double" in C, but that may not be the best plan: long double isn't consistent across even mainstream platforms. On Windows it's just the same as "double"; on OS X and most (all?) flavours of Linux it's the ancient x87 80-bit format. On some PPC machines it's a double-double format. IMO, the only sane format for something called "quad" would be the IEEE 754 standard binary128 format, but there's almost no hardware support for that format (excluding IBM zSeries). So we'd have to maintain (or borrow) a software implementation, which would be a *lot* of work. (I don't know of good free non-GPL implementations already in existence.)

I'm personally a strong -1 on adding a quad type to the Python core language: I don't think the extra complication is worth it. But if you want to take this further, I'd suggest taking it to the python-ideas mailing list: https://mail.python.org/mailman/listinfo/python-ideas. 
I'm going to close the issue here: adding quad is too big a proposed change for a tracker issue; I'm sure lots of people would weigh in on a python-ideas discussion.
History
Date User Action Args
2022-04-11 14:58:25adminsetgithub: 70092
2015-12-18 14:12:31mark.dickinsonsetstatus: open -> closed
resolution: rejected
2015-12-18 14:07:08mark.dickinsonsetnosy: + mark.dickinson
messages: + msg256682
2015-12-18 12:23:27Devyn Johnsoncreate