[Python-ideas] Python Numbers as Human Concept Decimal System

[MRAB]

On 2014-03-06 23:59, Cameron Simpson wrote:
> Coming to this very late, but I was interested in the first thread...
>
> On 05Mar2014 23:04, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Wed, Mar 05, 2014 at 11:29:10AM +0000, Oscar Benjamin wrote:
>> > I don't agree with Mark's proposal in this thread but I would like to
>> > have decimal literals e.g. 1.23d,
>>
>> +1 on that. Although that will depend on how big a slowdown it causes to
>> Python's startup time.
>
> +1 on 123d decimal literals.
>
>> > and I would also use Fraction
>> > literals if available e.g. 1/3F.
>>
>> Out of curiosity, why F rather than f?
>
> Well, for me, +1 on 123f for "IEEE float" literals. i.e. the floats
> in play in Python right now.
>
> If ever we get ambiguity on how numbers are done, this may be useful
> in the transition or experiment phase.
>
> So of course "F" is reasonable for fractions. But how hard does
> that make the grammar? Because the parser now has to grab the entire
> "1/3F" to construct the fraction. You can't just stick it in the lexer
> at that point.
>
I think it would be confusing if there were "f" for "float" and "F" for
"fraction". How about "r" for "rationals"?

> Aside: Unless you do something obtuse, like make "3F" be a regular
> number with a special internal flag which is treated differently
> on the right hand side of a division operation: if encoutered,
> division now returns a Fraction instead of an int or float; this
> feels like something that could easily have nasty side effects.
>
> And, speaking personally, a big -1 on Mark's "abstract all the
> numbers". Like other posters, I agree that a number's internal
> implementation/representation affects its semantics. You can't just
> wave a wand and say "it should all be abstract"; there will be
> side-effects.
>
> You can wave a wand and say "from here on in this code, unadorned
> numbers make Decimals, not IEEE floats".
>
> I'm +0.5 on something like:
>
>    from __future__ import decimal_floats
>
> to imply making Decimals from unadorned literals. "__future__" may
> be the wrong pseudomodule name.
>
> Not least, it makes testing the side-effects much easier because you
> can tweak a nice big chunk of code without editing it internally.
>
>> (By the way, I think it is somewhat amusing that Python not only has a
>> built-in complex type, but also *syntax* for creating complex numbers,
>> but no built-in support for exact rationals.)
>
<pedantic>Python doesn't have a syntax for creating complex numbers; it
has a syntax for creating imaginary numbers.</pedantic>

> Harder to parse (see above), smaller use case maybe. It is not a
> bad idea, just not yet done...
>