On 21 September 2017 at 10:44, Chris Barker - NOAA Federal
firstname.lastname@example.org wrote: [Thibault]
To sum up:
Right. But it addresses all of the points you make. The functionality is there. Making a new literal will buy a slight improvement in writability and performance.
Is that worth much in a dynamic language like python?
I think so, as consider this question: how do you write a script that accepts a user-supplied string (e.g. from a CSV file) and treats it as hex floating point if it has the 0x prefix, and decimal floating point otherwise?
You can't just blindly apply float.fromhex(), as that will also treat unprefixed strings as hexadecimal:
float.fromhex("0x10") 16.0 float.fromhex("10") 16.0
So you need to do the try/except dance with ValueError instead:
try: float_data = float(text) except ValueError: float_values = float.fromhex(text)
At which point you may wonder why you can't just write "float_data = float(text, base=0)" the way you can for integers:
int("10", base=0) 10 int("0x10", base=0) 16
And if the float() builtin were to gain a "base" parameter, then it's only a short step from there to allow at least the "0x" prefix on literals, and potentially even "0b" and "0o" as well.
So I'm personally +0 on the idea - it would improve interface consistency between integers and floating point values, and make it easier to write correctness tests for IEEE754 floating point hardware and algorithms in Python (where your input & output test vectors are going to use binary or hex representations, not decimal).
-- Nick Coghlan | email@example.com | Brisbane, Australia