This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author meador.inge
Recipients MrJean1, ajaksu2, barry, benjamin.peterson, mark.dickinson, meador.inge, pitrou, teoliphant
Date 2010-02-17.03:30:15
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
In-reply-to <>
Hi All,

On Sat, Feb 13, 2010 at 5:07 AM, Mark Dickinson <>wrote:

> Mark Dickinson <> added the comment:
> Some of the proposed struct module additions look far from straightforward;
>  I find that section of the PEP significantly lacking in details and
> motivation.

I agree.

> "Unpacking a long-double will return a decimal object or a ctypes
> long-double."
> Returning a Decimal object here doesn't make a lot of sense, since Decimal
> objects aren't generally compatible with floats.  And ctypes long double
> objects don't seem to exist, as far as I can tell.  It might be better not
> to add this code.

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


Another bit that's not clear to me:  how is unpacking an object pointer
> expected to work, and how would it typically be used?  What if the unpacked
> pointer no longer points to a valid Python object?  How would this work in
> other Python implementations?

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.

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

I read that as a Python function.  However, I am not completely sure how the
prototype would be enforced when unpacking.  I am also wondering, though,
how the signatures on pointers-to-functions are specified?  Are
the arguments and return type full struct strings as well?

> What's a 'specific pointer'?

I think this means a pointer to a specific type, e.g. '&d' is a pointer to a
double. If this is the case, though, the use cases are not completely clear
to me.

I also have the following questions:

* Can pointers be nested, '&&d' ?
* What nesting level can structures have? Arbitrary?
* The new array syntax claims "multi-dimensional array of whatever follows".

  Truly whatever? Arrays of structures? Arrays of pointers?
* "complex (whatever the next specifier is)".  Not really 'whatever'.  You
  can not have a 'complex bool' or 'complex int'.  What other types of
  complex are there besides complex double?
* How do array specifiers and pointer specifiers mix?  For example, would
  '(2, 2)&d' be a two-by-two array of pointers to doubles?  What about
  '&(2, 2)d'?  Is this a pointer to an two-by-two array of doubles?

The new features of the struct-string syntax are so different that I think
need to specify a grammar.  I think it will clarify some of the open

In addition, I was thinking that a reasonable implemenation strategy would
be to keep the current struct-string syntax mostly in place within the C
implementation.  The C implementation would just provide an interface to
pack\unpack sequences of primitive data elements.  Then we could write a
layer in the Python 'struct' module that took care of the higher-order
concepts like nested structures, arrays, named values, and pointers to
functions.  The higher-order concepts would be mapped to the appropriate
primitive sequence strings.

I think this will simplify the implementation and will provide a way to
it.  We can implement the primitive type extensions in C first followed by
the higher-level Python stuff.  The result of each phase is immediately

I have attached a patch against the PEP containing my current thoughts on
fleshing out the grammar and some of the current open questions.  This still
needs work, but I wanted to share to see if I am on the right track.
 Please advise on how to proceed.
File name Uploaded
pep-3118.patch meador.inge, 2010-02-17.03:30:13
unnamed meador.inge, 2010-02-17.03:30:10
Date User Action Args
2010-02-17 03:30:18meador.ingesetrecipients: + meador.inge, barry, teoliphant, mark.dickinson, pitrou, ajaksu2, MrJean1, benjamin.peterson
2010-02-17 03:30:15meador.ingelinkissue3132 messages
2010-02-17 03:30:15meador.ingecreate