Issue 1151323: New fpconst module (original) (raw)

Created on 2005-02-24 20:06 by warnes, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
fpconst.patch warnes,2005-02-24 20:06 fpconst module patch
Messages (12)
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) * (Python committer) 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) * (Python committer) 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) (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-11 14:56:09 admin set github: 41620
2009-02-10 19:53:59 mark.dickinson set status: open -> closedresolution: out of datemessages: +
2009-02-10 18:12:52 ajaksu2 set nosy: + mark.dickinson
2005-02-24 20:06:30 warnes create