Message106168
> 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. |
|
Date |
User |
Action |
Args |
2010-05-20 17:17:42 | meador.inge | set | recipients:
+ meador.inge, barry, teoliphant, mark.dickinson, pitrou, inducer, ajaksu2, MrJean1, benjamin.peterson, noufal, Alexander.Belopolsky |
2010-05-20 17:17:42 | meador.inge | set | messageid: <1274375862.13.0.0848329190215.issue3132@psf.upfronthosting.co.za> |
2010-05-20 17:17:40 | meador.inge | link | issue3132 messages |
2010-05-20 17:17:39 | meador.inge | create | |
|