[Python-Dev] PEP 3188: Implementation Questions

[Mark Dickinson]

On Fri, Feb 26, 2010 at 4:51 AM, Meador Inge <meadori at gmail.com> wrote:
>
> Recently some discussion began in the issue 3132 thread (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118.  Mark Dickinson
> suggested that I bring the discussion on over to Python Dev.  Below is a summary
> of the questions\comments from the thread.

Thanks for bringing this up here!

> Unpacking a long-double
> ===================
> ...

I don't want to dwell on this too much, since this is just one small
part of the proposed struct module additions, and I'd like to get
answers to some of the other questions you raised.  If interested
parties (Carl?, Travis?) have time to comment on the other questions
Meador raised, I'd *really* appreciate it!

For long-double: I'm essentially -1 on any Decimal involvement here,
on the basis that the semantics are messy and I doubt that the
resulting behaviour would match users' needs or expectations.  I'm
also not too keen on introducing a long-double-with-arithmetic type
(wherever it ends up living);  I think having a single (binary)
floating-point type has served Python very well, and adding other
binary float precisions would risk either adding significant
complexity, or leaving the extended precision type somewhat crippled.
If there were a long double type that supported arithmetic, how should
mixed-mode double + long double operations behave?  What about
conversions of long doubles to and from decimal strings?  Should math
module and cmath module functions accept long double arguments, and if
so, what type result should they produce?  The fact that there are at
least 3 different common formats, before considering padding and byte
order, for long double (IEEE 80-bit extended used on x86, IEEE
binary128, and the so-called double-double format) isn't going to make
things any easier here.

I guess, in my currently not-very-informed state, I'd vote for:

  - packing and unpacking with the long double format expects and
produces a ctypes.long_double in native mode;  the long-double format
would match that of the platform.
  - non-native mode packing and unpacking aren't permitted, and raise
an exception.
  - to do arithmetic with long doubles, users would simply have to
convert to and from Python floats, accepting the loss of precision
that such conversion entails.

But I think I'm failing to understand the intended use-cases for this
(and other) additions.  Would it be possible for Carl or Travis, or
anyone else, to give some examples of situations where this would be
useful?  I don't doubt that such situations exist;  I'm just not sure
what they are.

> Pointers
> ======
> [...]
> 2. How would unpacking a pointer to a Python Object work out?  Given an
>     address how would the appropriate object to be unpacked be determined?

Again, I'd really like to see some examples of how/when packing and
unpacking pointers to Python objects would be used;  I'm currently
feeling too stupid to understand how this might work in practice.

> 4. For the 'X{}' format (pointer to a function), is this supposed to mean a
>     Python function or a C function?

Ditto for this;  assuming that we're talking about a Python function here.

> String Syntax
> ==========
>
> The syntax seems to have transcended verbal description.  I think we
> need to put forth a grammar.

Agreed:  a clear specification is needed.

> Use Cases
> ========
>
>    1. What are the real world use cases for these struct string extensions?
>       These should be fleshed out and documented.

+many.

Mark