[Patches] [ python-Patches-1151323 ] New fpconst module

SourceForge.net noreply at sourceforge.net
Sun Feb 18 10:09:07 CET 2007


Patches item #1151323, was opened at 2005-02-24 21:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gregory Warnes (warnes)
Assigned to: Nobody/Anonymous (nobody)
Summary: New fpconst module

Initial Comment:
This patch adds the 'fpconst' module, described in
PEP754 to the standard python library.  It includes
both the source code and the documentation.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-18 10:09

Message:
Logged In: YES 
user_id=21627
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Nick Guenther (kousu)
Date: 2007-02-15 18:50

Message:
Logged In: YES 
user_id=705725
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-15 11:03

Message:
Logged In: YES 
user_id=21627
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Gregory Warnes (warnes)
Date: 2006-02-21 17:10

Message:
Logged In: YES 
user_id=9316

Yes, there is still interest in getting this into 2.5.

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:04

Message:
Logged In: YES 
user_id=849994

Is there an interest of getting this into 2.5?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-07-14 14:27

Message:
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.

----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2005-03-01 19:53

Message:
Logged In: YES 
user_id=356893

There are some typos in the docstrings: in[i]finity and
exponent[ent].

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-03-01 03:24

Message:
Logged In: YES 
user_id=139309

Maybe you did something wrong, because I tried it and it worked fine.

----------------------------------------------------------------------

Comment By: Gregory Warnes (warnes)
Date: 2005-03-01 03:20

Message:
Logged In: YES 
user_id=9316

Response to etrepum:

Actually, I tried using '!' and '>' without success before
resorting to the big_endian_ check...

-Greg

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2005-02-25 01:25

Message:
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 >

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1151323&group_id=5470


More information about the Patches mailing list