Coming to this very late, but I was interested in the first thread...
On 05Mar2014 23:04, Steven D'Aprano email@example.com 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...
Cameron Simpson firstname.lastname@example.org
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.)