[Python-ideas] Python Float Update

[Andrew Barnert]

On Jun 2, 2015, at 02:38, Alexander Walters <tritium-list at sdamon.com> wrote:
> 
> I think there is another discussion to have here, and that is making Decimal part of the language (__builtin(s)__) vs. part of the library (which implementations can freely omit).

I don't think there is any such distinction in Python.

Neither the language reference nor the library reference claims to be a specification.

The library documentation specifically says that it "describes the standard library that is distributed with Python" and "also describes some of the optional components that are commonly included in Python  distributions", which implies that, except for the handful of modules that are described as optional or platform-specific, everything should always be there. (There is special dispensation for Unix systems to split up Python into separate packages, but even that is specifically limited to "some or all of the optional components".)

Historically, implementations that haven't included the entire stdlib also haven't included parts of the language (Jython 2.2 and early 2.5 versions, early versions of PyPy, the various browser-based implementations, MicroPython and PyMite, etc.).

Also, both the builtins module and the actual built-in functions, constants, types, and exceptions it contains are documented as part of the library, just like decimal, not as part of the language.

So, Python isn't like C, with separate specifications for "freestanding" vs. "hosted" implementations, and it doesn't have a separate specification for an "embedded" subset like C++ used to.

> If it were part of the language, then maybe, just maybe, a literal syntax should be considered.

Since there is no such distinction between language and library, I think we're free to define a literal syntax for decimals and fractions.

From a practical point of view (which beats purity, of course), it's probably not reasonable for CPython to define such literals unless there's a C implementation that defines the numeric type slot (and maybe even has a C API concrete type interface, although maybe not), and which can be "frozen" at build time. (See past discussions on adding an OrderedDict literal for why these things are important.) 

That's currently true for Decimal, but not for Fraction. So, that might be an argument against fraction literals, or for providing a C implementation of the fraction module.

> As it stands, Decimal and Fraction are libraries - implementations of python are free to omit them (as I think some of the embedded platform implementations do), and it currently does not make a lick of sense to add syntax for something that is only in the library.

Even besides the four library sections on the various kinds of built-in things, plenty of other things are syntax for something that's "only in the library". The import statement is defined in terms of functionality in importlib, and (at least in CPython) actually implemented that way.

In fact, numeric values, as defined in the data model section of the language reference, are defined in terms of types from the library docs, both in stdtypes and  in the numbers module. Defining decimal values in terms of types defined in the decimal module library section would be no different. (Numeric _literals_ don't seem to have their semantics defined anywhere, just their syntax, but it's pretty obvious from the wording that they're intended to have int, float, and complex values as defined by the data model--which, again, means as defined by the library.)

So, while there are potentially compelling arguments against a decimal literal (how it interacts with contexts may be confusing, the idea may be too bikesheddable to come up with one true design that everyone will like, or may be an attractive nuisance, it may add too much complexity to the implementation for the benefit, etc.), "decimal is only a library" doesn't seem to be one.

>> On 6/2/2015 04:19, M.-A. Lemburg wrote:
>>> On 02.06.2015 03:37, Steven D'Aprano wrote:
>>>> On Mon, Jun 01, 2015 at 05:52:35PM +0300, Joonas Liik wrote:
>>>> 
>>>> Having some sort of decimal literal would have some advantages of its own,
>>>> for one it could help against this sillyness:
>>>> 
>>>>>>> Decimal(1.3)
>>>> Decimal('1.3000000000000000444089209850062616169452667236328125')
>>> Why is that silly? That's the actual value of the binary float 1.3
>>> converted into base 10. If you want 1.3 exactly, you can do this:
>>> 
>>>>>>> Decimal('1.3')
>>>> Decimal('1.3')
>>> Is that really so hard for people to learn?
>> Joonas, I think you're approaching this from the wrong angle.
>> 
>> People who want to get an exact decimal from a literal, will
>> use the string representation to define it, not a float
>> representation.
>> 
>> In practice, you typically read the data from some file or stream
>> anyway, so it already comes as string value and if you want to
>> convert an actual float to a decimal, this will most likely
>> not be done in a literal way, but instead by passed in to
>> the Decimal constructor as variable, so there's no literal
>> involved.
>> 
>> It may be good to provide some alternative ways of converting
>> a float to a decimal, e.g. one which uses the float repr logic
>> to overcome things like repr(float(1.1)) == '1.1000000000000001'
>> instead of a direct conversion:
>> 
>>>>> Decimal(1.1)
>> Decimal('1.100000000000000088817841970012523233890533447265625')
>>>>> Decimal(repr(1.1))
>> Decimal('1.1')
>> 
>> These could be added as parameter to the Decimal constructor.
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150602/ee9398c5/attachment-0001.html>