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