Re: [Python-ideas] Hexadecimal floating literals
Hi everyone
>> Of course, for a lost of numbers, the decimal representation is simpler, and
>> just as accurate as the radix-2 hexadecimal representation.
>> But, due to the radix-10 and radix-2 used in the two representations, the
>> radix-2 may be much easier to use.
>
> Hex is radix 16, not radix 2 (binary).
Of course, Hex is radix-16!
I was talking about radix-2 because all the exactness problem comes when
converting binary and decimal, and Hex can be seen as an (exact) compact way to
express binary, and that's what we want (build literal floats in the same exact
way they are stored internally, and export them exactly in a compact way).
>
>> In the "Handbook of Floating-Point Arithmetic" (JM Muller et al, Birkhauser
>> editor, page 40),the authors claims that the largest exact decimal
>> representation of a double-precision floating-point requires 767 digits !!
>> So it is not always few characters to type to be just as accurate !!
>> For example (this is the largest exact decimal representation of a
>> single-precision 32-bit float):
>>> 1.1754942106924410754870294448492873488270524287458985717453057158887047561890426550235133618116378784179687e-38
>> and
>>> 0x1.fc000p-127
>> are exactly the same number (one in decimal representation, the other in
>> radix-2 hexadecimal)!
>
> That may be so, but that doesn't mean you have to type all 100+ digits
> in order to reproduce the float exactly. Just 1.1754942106924411e-38 is
> sufficient:
>
> py> 1.1754942106924411e-38 == float.fromhex('0x1.fc000p-127')
> True
>
> You may be mistaking two different questions:
>
> (1) How many decimal digits are needed to exactly convert the float to
> decimal? That can be over 100 for a C single, and over 700 for a double.
>
> (2) How many decimal digits are needed to uniquely represent the float?
> Nine digits (plus an exponent) is enough to represent all possible C
> singles; 17 digits is enough to represent all doubles (Python floats).
You're absolutely right, 1.1754942106924411e-38 is enough to *reproduce* the
float exactly, BUT it is still different to 0x1.fc000p-127 (or it's
112-digits decimal representation).
Because 1.1754942106924411e-38 is rounded at compile-time to
0x1.fc000p-127 (so exactly to
1.1754942106924410754870294448492873488270524287458985717453057158887047561890426550235133618116378784179687e-38
in decimal).
So 17 digits are enough to reach each double, after the compile-time
quantization. But "explicit is better than implicit", as someone says ;-), so I
prefer, in some particular occasions, to explicitly express the floating-point
number I want (like 0x1.fc000p-127), rather than hoping the
quantization of my decimal number (1.1754942106924411e-38) will produce the
right floating-point (0x1.fc000p-127)
And that's one of the reasons why the hexadecimal floating-point representation
exist:
- as a way to *exactly* export floating-point numbers without any doubt (so
give a compact form of if binary intern representation)
- as a way to *explicitly* and *exactly* specify some floating-point values in
your code, directly in the way they are store internally (in a compact way,
because binary is too long)
> I'm not actually opposed to hex float literals. I think they're cool.
> But we ought to have a reason more than just "they're cool" for
> supporting them, and I'm having trouble thinking of any apart from "C
> supports them, so should we". But maybe that's enough.
To sum up:
- In some specific context, hexadecimal floating-point constants make it easy
for the programmers to reproduce the exact value. Typically, a software
engineer who is concerned about floating-point accuracy would prepare
hexadecimal floating-point constants for use in a program by generating them
with special software (e.g., Maple, Mathematica, Sage or some multi-precision
library). These hexadecimal literals have been added to C (since C99), Java,
Lua, Ruby, Perl (since v5.22), etc. for the same reasons.
- The exact grammar has been fully documented in the IEEE-754-2008 norm
(section 5.12.13), and also in C99 (or C++17 and others)
- Of course, hexadecimal floating-point can be manipulated with float.hex() and
float.fromhex(), *but* it works from strings, and the translation is done at
execution-time...
I hope this can be seen as a sufficient reason to support hexadecimal floating
literals.
Thibault
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
> Quality is something that an organisation and its people need to achieve by > building appropriate processes and improvement methods into their work flow. > Trying to be prescriptive will run into trouble for the wider world I suspect. > > Many of the maintainability metrics may help a team. > > However peer review and discussion within teams is a powerful process to > achieve good code, which is process. > > I do not see quality as a quantity that can be easily measured. > How can we set a minimum for the hard to measure? Since the proposal first came out, I've been wondering about it's implications. I do think that there is some virtue to having it, but it quickly gets messy. In terms of quality as a quantity, the minimal would be to break on a linting error. JSHint has numbered issues: /* jshint -W034 */ Having a decorator of @pylint-034 could tell PyLint or python proper to refuse compilation/execution if the standard is not met. So would we limit or list the various standards that apply to the code? Do we limit it on a per-function or per file, or even per-line basis? How do we handle different organizational requirements? @pylint([34]) @pep([8,20]) def f(a): return math.sqrt(a) The other aspect that comes into code quality is unit tests. A decorator of what test functions need to be run on a function (and pass) would also be useful: def test_f_arg_negative(f): try: return f(-1) == 1 except(e): return False# ValueError: math domain error @tests([test_f_arg_positive, test_f_arg_negative, test_f_arg_zero, f_test_f_arg_int, test_f_arg_float]) def f(a): return math.sqrt(math.abs(a)) In a test-driven world, the test functions would come first, but this is rarely the case. Possible results are not just test failure, but also that a test does not yet exist. I think it would be great to know what tests the function is supposed to pass. The person coding the function has the best idea of what inputs it is expected to handle and side-effects it should cause. Hunting through a test kit for the function is usually tedious. This I think would vastly improve it while taking steps to describe and enforce 'quality' Just my $0.02 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
> How do we handle different organizational requirements? > By keeping linting out of the code ( and certainly out of "official" python), and in the organization's development process where it belongs. > @pylint([34]) > @pep([8,20]) > def f(a): > return math.sqrt(a) Yeach! But that's just my opinion -- if you really like this idea, you can certainly implement it in an external package. No need for a PEP or anything of the sort. > The other aspect that comes into code quality is unit tests. A decorator of > what test functions need to be run on a function (and pass) would also be > useful: > > def test_f_arg_negative(f): > try: >return f(-1) == 1 > except(e): >return False# ValueError: math domain error > > @tests([test_f_arg_positive, test_f_arg_negative, test_f_arg_zero, > f_test_f_arg_int, test_f_arg_float]) > def f(a): > return math.sqrt(math.abs(a)) Again, I don't think it belongs there, but I do see your point. If you like this idea--implement it, put it on PyPi, and see if anyone else likes if as well. -CHB ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
> > How do we handle different organizational requirements? > > > By keeping linting out of the code ( and certainly out of "official" > python), and in the organization's development process where it > belongs. > > > @pylint([34]) > > @pep([8,20]) > > def f(a): > > return math.sqrt(a) > > Yeach! But that's just my opinion -- if you really like this idea, you > can certainly implement it in an external package. No need for a PEP > or anything of the sort. > > > The other aspect that comes into code quality is unit tests. A decorator of > > what test functions need to be run on a function (and pass) would also be > > useful: > > > > def test_f_arg_negative(f): > > try: > >return f(-1) == 1 > > except(e): > >return False# ValueError: math domain error > > > > @tests([test_f_arg_positive, test_f_arg_negative, test_f_arg_zero, > > f_test_f_arg_int, test_f_arg_float]) > > def f(a): > > return math.sqrt(math.abs(a)) > > Again, I don't think it belongs there, but I do see your point. If you > like this idea--implement it, put it on PyPi, and see if anyone else > likes if as well. Not my idea, but the question was raised as to what could a 'quality guarantee' or 'quality' even mean. I was just throwing out examples for discussion. I did not intend to make you vomit. I think in an abstract sense it's a good idea, but in my own head I would expect that all code to be written to the highest standard from the start. I have some nascent ideas, but they are not even worth mentioning yet, and I don't even know how they'd fit in any known language. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
Hi, Thanks to everyone for your contribution to my proposal. @Barry, I agree with you that each organisation needs to integrate the "quality process" in their workflow. But before integrate it, this "quality" process need to be define, at minimal, i think. I don't think too this is easy to measure, in integrity, but we can define minimal metric, easy to get from code, as the ones defines previously. About your question for googlegroups, i don't know if it's bond, but i use google group to participate to this mailing list. @Jason, thanks for your example. When i discussed from this proposal with other devs of my team, they needed too example to have better idea of use. But i think, as wee need to avoid to talk about any tool name in the PEP, we need to avoid to give a code example. The aim of this proposal is to have a guideline on minimal metrics to have minimal quality. As you talked about, i ask to every devs of my team to respect the higher standard as possible. This, and the permanent request of my customers for the highest dev quality as possible, is the reason which explain this proposal. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
> On 20 Sep 2017, at 20:02, alexandre.gal...@gmail.com wrote: > > Hi, > > Thanks to everyone for your contribution to my proposal. > > @Barry, I agree with you that each organisation needs to integrate the > "quality process" in their workflow. But before integrate it, this "quality" > process need to be define, at minimal, i think. I don't think too this is > easy to measure, in integrity, but we can define minimal metric, easy to get > from code, as the ones defines previously. About your question for > googlegroups, i don't know if it's bond, but i use google group to > participate to this mailing list. The organisations work flow *is* its quality process, for better or worse. You can define metrics. But as to what they mean? Well that is the question. I was once told that you should measure a new metric for 2 years before you attempting to use it to change your processes. Oh and what is the most important thing for a piece of work? I'd claim its the requirements. Get them wrong and nothing else matters. Oh and thank you for raising a very important topic. Barry > > @Jason, thanks for your example. When i discussed from this proposal with > other devs of my team, they needed too example to have better idea of use. > But i think, as wee need to avoid to talk about any tool name in the PEP, we > need to avoid to give a code example. The aim of this proposal is to have a > guideline on minimal metrics to have minimal quality. As you talked about, i > ask to every devs of my team to respect the higher standard as possible. > This, and the permanent request of my customers for the highest dev quality > as possible, is the reason which explain this proposal. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
> You can define metrics. But as to what they mean? Well that is the question. One big problem with metrics is that we tend to measure what we know how to measure -- generally really not the most useful metric... As for some kind of PEP or PEP-like document: I think we'd have to see a draft before we have any idea as to whether it's a useful document -- if some of the folks on this thread are inspired -- start writing! I, however, am skeptical because of two things: 1) most code-quality measures, processes, etc are not language specific -- so don't really belong in a PEP So why PEP 8? -- because the general quality metric is: " the source code confirms to a consistent style" -- there is nothing language specific about that. But we need to actually define that style for a given project or organization -- hence PEP 8. 2) while you can probably get folks to agree on general guidelines-- tests are good! -- I think you'll get buried in bike shedding of the details. And it will likely go beyond just the color of the bike shed. Again -- what about PEP8? Plenty of bike shedding opportunities there. But there was a need to reach consensus on SOMETHING-- we needed a style guide for the standard lib. I'm not that's the case with other "quality" metrics. But go ahead and prove me wrong! -CHB > > I was once told that you should measure a new metric for 2 years before you > attempting to use it to change your processes. > > Oh and what is the most important thing for a piece of work? > > I'd claim its the requirements. Get them wrong and nothing else matters. > > Oh and thank you for raising a very important topic. > > Barry > > >> >> @Jason, thanks for your example. When i discussed from this proposal with >> other devs of my team, they needed too example to have better idea of use. >> But i think, as wee need to avoid to talk about any tool name in the PEP, we >> need to avoid to give a code example. The aim of this proposal is to have a >> guideline on minimal metrics to have minimal quality. As you talked about, i >> ask to every devs of my team to respect the higher standard as possible. >> This, and the permanent request of my customers for the highest dev quality >> as possible, is the reason which explain this proposal. >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Hexadecimal floating literals
> And that's one of the reasons why the hexadecimal floating-point > representation exist: I suspect no one here thinks floathex representation is unimportant... > > To sum up: > - In some specific context, hexadecimal floating-point constants make it > easy for the programmers to reproduce the exact value. Typically, a software > engineer who is concerned about floating-point accuracy would prepare > hexadecimal floating-point constants for use in a program by generating them > with special software (e.g., Maple, Mathematica, Sage or some multi-precision > library). These hexadecimal literals have been added to C (since C99), Java, > Lua, Ruby, Perl (since v5.22), etc. for the same reasons. > - The exact grammar has been fully documented in the IEEE-754-2008 norm > (section 5.12.13), and also in C99 (or C++17 and others) > - Of course, hexadecimal floating-point can be manipulated with float.hex() > and float.fromhex(), *but* it works from strings, and the translation is done > at execution-time... 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? -CHB ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
On 9/20/17 8:37 PM, Chris Barker - NOAA Federal wrote: You can define metrics. But as to what they mean? Well that is the question. One big problem with metrics is that we tend to measure what we know how to measure -- generally really not the most useful metric... As for some kind of PEP or PEP-like document: I think we'd have to see a draft before we have any idea as to whether it's a useful document -- if some of the folks on this thread are inspired -- start writing! I, however, am skeptical because of two things: 1) most code-quality measures, processes, etc are not language specific -- so don't really belong in a PEP So why PEP 8? -- because the general quality metric is: " the source code confirms to a consistent style" -- there is nothing language specific about that. But we need to actually define that style for a given project or organization -- hence PEP 8. 2) while you can probably get folks to agree on general guidelines-- tests are good! -- I think you'll get buried in bike shedding of the details. And it will likely go beyond just the color of the bike shed. Again -- what about PEP8? Plenty of bike shedding opportunities there. But there was a need to reach consensus on SOMETHING-- we needed a style guide for the standard lib. I'm not that's the case with other "quality" metrics. I don't see the need for a PEP here. PEPs are written where we need the core committers to agree on something (how to change Python, how to style stdlib code, etc), or where we need multiple implementations to agree on something (what does "python" mean, how to change Python, etc). There's no need for the core committers or multiple implementations of Python to agree on quality metrics. There's no need for this to be a PEP. Write a document that proposes some quality metrics. Share it around. Get people to like it. If it becomes popular, then people will start to value it as a standard for project quality. It doesn't need to be a PEP. --Ned. But go ahead and prove me wrong! -CHB I was once told that you should measure a new metric for 2 years before you attempting to use it to change your processes. Oh and what is the most important thing for a piece of work? I'd claim its the requirements. Get them wrong and nothing else matters. Oh and thank you for raising a very important topic. Barry @Jason, thanks for your example. When i discussed from this proposal with other devs of my team, they needed too example to have better idea of use. But i think, as wee need to avoid to talk about any tool name in the PEP, we need to avoid to give a code example. The aim of this proposal is to have a guideline on minimal metrics to have minimal quality. As you talked about, i ask to every devs of my team to respect the higher standard as possible. This, and the permanent request of my customers for the highest dev quality as possible, is the reason which explain this proposal. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Hexadecimal floating literals
On 21 September 2017 at 10:44, Chris Barker - NOAA Federal
wrote:
[Thibault]
>> To sum up:
>> - In some specific context, hexadecimal floating-point constants make it
>> easy for the programmers to reproduce the exact value. Typically, a software
>> engineer who is concerned about floating-point accuracy would prepare
>> hexadecimal floating-point constants for use in a program by generating them
>> with special software (e.g., Maple, Mathematica, Sage or some
>> multi-precision library). These hexadecimal literals have been added to C
>> (since C99), Java, Lua, Ruby, Perl (since v5.22), etc. for the same reasons.
>> - The exact grammar has been fully documented in the IEEE-754-2008 norm
>> (section 5.12.13), and also in C99 (or C++17 and others)
>> - Of course, hexadecimal floating-point can be manipulated with float.hex()
>> and float.fromhex(), *but* it works from strings, and the translation is
>> done at execution-time...
>
> 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).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP to define basical metric which allows to guarantee minimal code quality
On 21 September 2017 at 10:51, Ned Batchelder wrote: > Write a document that proposes some quality metrics. Share it around. Get > people to like it. If it becomes popular, then people will start to value it > as a standard for project quality. And explore the academic literature for research on quality measures that are actually predictors of real world benefits (e.g. readability, maintainability, correctness, affordability). There doesn't seem to be all that much research out there, although I did find https://link.springer.com/chapter/10.1007/978-3-642-12165-4_24 from several years ago, as well as http://ieeexplore.ieee.org/document/7809284/ from last year (both are examples of pay-to-play science though, so not particularly useful to open source practitioners). Regardless, Ned's point still stands: the PEP process only applies to situations where the CPython core developers (or a closely associated group like the Python Packaging Authority) are the relevant global authorities on a topic. Even PEP 7 and PEP 8 are technically only the style guides for the CPython reference implementation - folks just borrow them as the baseline style guides for their own Python projects. "Which characteristics of Python code are useful predictors of the ability to deliver software projects to specification on time and within budget?" (the most pragmatic definition of "software quality") is *not* one of those areas - for that, you'd be more looking towards groups like IEEE (Institute of Electrical & Electronics Engineers) and ACM (Association for Computing Machinery), who study that kind of thing across multiple languages and language communities, and try to put some empirical weight behind their findings, rather than relying primarily on instinct and experience (which is the way we tend to do things in the open source community, since it's more fun, and less effort). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Hexadecimal floating literals
Yeah, I agree, +0. It won't confuse anyone who doesn't care about it and
those who need it will benefit.
On Wed, Sep 20, 2017 at 6:13 PM, Nick Coghlan wrote:
> On 21 September 2017 at 10:44, Chris Barker - NOAA Federal
> wrote:
> [Thibault]
> >> To sum up:
> >> - In some specific context, hexadecimal floating-point constants make
> it easy for the programmers to reproduce the exact value. Typically, a
> software engineer who is concerned about floating-point accuracy would
> prepare hexadecimal floating-point constants for use in a program by
> generating them with special software (e.g., Maple, Mathematica, Sage or
> some multi-precision library). These hexadecimal literals have been added
> to C (since C99), Java, Lua, Ruby, Perl (since v5.22), etc. for the same
> reasons.
> >> - The exact grammar has been fully documented in the IEEE-754-2008 norm
> (section 5.12.13), and also in C99 (or C++17 and others)
> >> - Of course, hexadecimal floating-point can be manipulated with
> float.hex() and float.fromhex(), *but* it works from strings, and the
> translation is done at execution-time...
> >
> > 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).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Hexadecimal floating literals
On Thu, Sep 21, 2017 at 11:13:44AM +1000, Nick Coghlan wrote:
> 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?
float.fromhex(s) if s.startswith('0x') else float(s)
[...]
> 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
I agree with your arguments. I just wish I could think of a good reason
to make it +1 instead of a luke-warm +0.
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
