msg47847 - (view) |
Author: Gregory Warnes (warnes) * |
Date: 2005-02-24 20:06 |
This patch adds the 'fpconst' module, described in PEP754 to the standard python library. It includes both the source code and the documentation. |
|
|
msg47848 - (view) |
Author: Bob Ippolito (bob.ippolito) *  |
Date: 2005-02-25 00:25 |
Logged In: YES user_id=139309 Is there a reason why you don't use the struct.pack endian markers? You could get rid of all the code that deals with _big_endian if you just prefixed the formats with ! or > |
|
|
msg47849 - (view) |
Author: Gregory Warnes (warnes) * |
Date: 2005-03-01 02:20 |
Logged In: YES user_id=9316 Response to etrepum: Actually, I tried using '!' and '>' without success before resorting to the big_endian_ check... -Greg |
|
|
msg47850 - (view) |
Author: Bob Ippolito (bob.ippolito) *  |
Date: 2005-03-01 02:24 |
Logged In: YES user_id=139309 Maybe you did something wrong, because I tried it and it worked fine. |
|
|
msg47851 - (view) |
Author: Richard Brodie (leogah) |
Date: 2005-03-01 18:53 |
Logged In: YES user_id=356893 There are some typos in the docstrings: in[i]finity and exponent[ent]. |
|
|
msg47852 - (view) |
Author: Michael Hudson (mwh)  |
Date: 2005-07-14 12:27 |
Logged In: YES user_id=6656 For Python 2.5 you should indeed be able to use the "<d" struct format and have it behave itself. Also, you should probably do something like: if not float.__getformat__('double').startswith('IEEE'): raise ImportError, "platform appears not to support IEEE arithmetic" In my experience, isNaN and isInf are usually spelt isnan and isinf (e.g. in C99), and I'd prefer to keep it that way. The tests should go in a separate file, of course. |
|
|
msg47853 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2006-02-20 12:04 |
Logged In: YES user_id=849994 Is there an interest of getting this into 2.5? |
|
|
msg47854 - (view) |
Author: Gregory Warnes (warnes) * |
Date: 2006-02-21 16:10 |
Logged In: YES user_id=9316 Yes, there is still interest in getting this into 2.5. |
|
|
msg47855 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2007-02-15 10:03 |
This being a PEP, it can't go into Python without the PEP being accepted first, by BDFL pronouncement (see PEP 1). So as long as this hasn't happened, this patch cannot go in. |
|
|
msg47856 - (view) |
Author: Nick Guenther (kousu) |
Date: 2007-02-15 17:50 |
Wouldn't it be better to include this directly in the language, and have float.isNaN(), float.isInf(), ..., or perhaps globals inNaN(), ..., ? In any case, what would it take to move this forward then? Python is sorely lacking this. |
|
|
msg47857 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2007-02-18 09:09 |
kousu: write a competing PEP, or work with the author of PEP 754 to revise his specification. This tracker is inappropriate to design the feature given that there is a PEP available. Please follow the procedure for Python enhancements. |
|
|
msg81591 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2009-02-10 19:53 |
Since PEP 754 has been rejected, I think this issue can be closed. As noted at the top of PEP 754, much of the functionality of the patch is already included (in somewhat different form) in 2.6 and 3.0. |
|
|