On 03/05/2014 02:32 PM, Andrew Barnert wrote:
I don't agree with Mark's proposal in this thread but I would like to have decimal literals e.g. 1.23d, and I would also use Fraction literals if available e.g. 1/3F.
I agree with you completely on that. That's kind of my point—your suggestion is almost the_opposite_ of the proposal in this thread. You want to make it easier for people to use the appropriate type for each use case; he wants to eliminate that choice entirely so you never have to make it. The latter would be nice if it were doable, but it's not even possible in principle. So the former is the best choice.
It's also a matter of how far in the future you are looking. If he waited until later to propose something like this, it most likely wouldn't get in. I'm not sure he's expecting a firm answer now, but probably is hoping for a "hey lets look into this more and see if it's really possible" kind of maybe. For that, it's good to start early.
On the near term, adding literal syntax's as you describe here would get all the pieces into python. Then an import from future could enable what Mark is thinking. He really needs to flesh out the details first before we can make any objective opinions about how it would actually work.
The way I see it, with a unified number type, we will still need context like api's to get the more specialised behaviours. The difference may be a decorator on a function that specifies some subset of number types to use rather than notating each literal and casting each value.
@numbers(int, decimal) def acounting_foo(...): ... # using ints for integers # using decimal for reals ...
That just a guess... maybe Mark can give some examples how what he's proposing would work. ?