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

[Cameron Simpson]

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.

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.)

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

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

The concept is interesting and well-formed, but in order to earn better than
a 'C,' the idea must be feasible.
      --A Yale University management professor in response to Fred
        Smith's paper proposing reliable overnight delivery service.
       (Smith went on to found  Federal Express Corp.)