Mark Dickinson <dicki...@gmail.com> added the comment:

> And under what conditions would a ctype long double be used vs. a
> Decimal object.

Well, I'm guessing that this was really just an open question for the PEP, and 
that the PEP authors hadn't decided which of these two options was more 
appropriate.  If all long doubles were converted to Decimal, then we need to 
determine what precision is appropriate to use for the conversion: any long 
double *can* be represented exactly as a Decimal, but to get an exact 
representation can need thousands of digits in some cases, so it's probably 
better to always round to some fixed number of signficant digits.  36 
significant digits is a reasonable choice here: it's the minimum number of 
digits that's guaranteed to distinguish two distinct long doubles, for the case 
where a long double has 113 bits of precision (i.e., IEEE 754 binary128 
format);  other common long double formats have smaller precision than this 
(usually 53 (normal double), 64 (x87 extended doubles), or 106 (double 
double)).  There would probably also need to be some way to 'repack' the 
Decimal instance.

The 'platform long double -> Decimal' conversion itself would also be 
nontrivial to implement;  I can lend a hand here if you want it.

Using ctypes makes more sense to me, since it doesn't involve trying to mix 
decimal and binary, except that I don't know whether it's acceptable for other 
standard library modules to have dependencies on ctypes.  I'm not sure whether 
ctypes is available on all platforms that Python runs on. It's also a bit ugly 
that, depending on the platform, sometimes a long double will unpack to an 
instance of ctypes.long_double, and sometimes (when long double == double) to a 
regular Python float.

Anyway, this particular case (long double) isn't a big deal:  it can be 
overcome, one way or another.  I'm more worried about some of the other aspects 
of the changes.

[About unpacking with the 'O' format.]
> I guess if an object associated with the packed address does not
> exist, then you would unpack None (?).  This is especially a problem 
> if the struct-sting is being sent over the wire to another machine.

And how do you determine whether an address gives a valid object or not?  I can 
only assume that packing and unpacking with the 'O' format is only supposed to 
be used in certain restricted circumstances, but it's not clear to me what 
those circumstances are.

> I also have the following questions: [...]

I think a lot of this discussion needs to go back to python-dev;  with luck, we 
can get some advice and clarifications from the PEP authors there.  I'm not 
sure whether it's appropriate to modify the original PEP (especially since it's 
already accepted), or whether it would be better to produce a separate document 
describing the proposed changes in detail.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to