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 Alexander.Belopolsky, MrJean1, ajaksu2, barry, benjamin.peterson, inducer, mark.dickinson, meador.inge, noufal, pitrou, teoliphant
Date 2010-05-20.17:17:39
SpamBayes Score 0.00049120333
Marked as misclassified No
Message-id <1274375862.13.0.0848329190215.issue3132@psf.upfronthosting.co.za>
In-reply-to
Content
> As a separate issue, I notice that the new 'T{}' code doesn't respect 
> multiplicities, e.g., as in 'H3T{HHL}'.  Is that 
> intentional/desirable?

That could have been an oversight on my part.  I don't see any immediate reason why we wouldn't allow it.

> But now I've got a new open issue:  how much padding should be 
> inserted/expected (for pack/unpack respectively) between the 'B' and 
> the 'T{...}' in a struct format string of the form 'BT{...}'?

Doesn't that depend on what is in the '...'?  For example, I would expect the same padding for 'BT{I}' and 'BI'.  In general, I would expect the padding to be the same for 'x+T{y+}' and 'x+y+'.  The 'T{...}'s are merely organizational, right?

> I'm tempted to suggest that for native mode, changing the specifier be 
> disallowed entirely.

I am tempted to suggest that we just go back to having one specifier at the beginning of the string :).  Things seem to be getting complicate without any clear benefits.
History
Date User Action Args
2010-05-20 17:17:42meador.ingesetrecipients: + meador.inge, barry, teoliphant, mark.dickinson, pitrou, inducer, ajaksu2, MrJean1, benjamin.peterson, noufal, Alexander.Belopolsky
2010-05-20 17:17:42meador.ingesetmessageid: <1274375862.13.0.0848329190215.issue3132@psf.upfronthosting.co.za>
2010-05-20 17:17:40meador.ingelinkissue3132 messages
2010-05-20 17:17:39meador.ingecreate