classification
Title: Allow array.array to be parsed by the t# format unit.
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.1
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, ajaksu2, gvanrossum, jyasskin, pitrou
Priority: normal Keywords:

Created on 2007-09-25 05:25 by jyasskin, last changed 2010-07-17 18:16 by BreamoreBoy. This issue is now closed.

Files
File name Uploaded Description Edit
let_t_format_take_array.patch jyasskin, 2007-09-25 05:25
Messages (7)
msg56126 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) Date: 2007-09-25 05:25
This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer
like all of the other buffer-using format units instead of
PyBUF_CHARACTER. Objects with multi-byte units wind up
byte-order-dependent. Alternately, it might make sense to have
array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag.

I haven't actually tested this patch on a big-endian machine.
msg56136 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-09-25 17:24
Hm, doesn't this make t and t# identical to s and s#?  Or if there are
still differences, are they still relevant?  I vaguely recall that t and
t# were introduced as variants of s and s# that requested char buffers.
 Since we're phasing out the whole idea of char buffers, perhaps there's
no longer a need for the distinction?
msg56138 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-09-25 18:29
Never mind.  s/s# has explicit support for unicode. There is no t; t#
requires a buffer that's not unicode (that's what PyBUF_CHARACTER
amounts to).

If there's one area I'd love to refactor it's getargs.c.
What a sprawling mess!

Also, we should kill PyBUF_CHARACTER completely.
msg87713 - (view) Author: Daniel Diniz (ajaksu2) (Python triager) Date: 2009-05-13 21:49
PyBUF_CHARACTER is now gone, and getargs.c reads:

          /*TEO: This can be eliminated --- here only for backward
            compatibility */
        case 't': { /* 8-bit character buffer, read-only access */
msg87816 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-05-15 13:01
I'm not sure what t# is for. Jeffrey, have you tried using y* instead?
(you must call PyBuffer_Release at the end)
msg87820 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) Date: 2009-05-15 15:58
I actually have no idea what I was trying to do when I ran into this. I
think it was a use somewhere in the standard libraries rather than my
own code, so if uses of t# are gone from there, I'd have no objections
to closing this bug.
msg110590 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-17 18:16
OP has stated it's ok to close.
History
Date User Action Args
2010-07-17 18:16:10BreamoreBoysetstatus: open -> closed

nosy: + BreamoreBoy
messages: + msg110590

resolution: not a bug
2009-05-15 15:58:04jyasskinsetmessages: + msg87820
2009-05-15 13:01:45pitrousetmessages: + msg87816
2009-05-13 21:49:47ajaksu2setversions: + Python 3.1, - Python 3.0
nosy: + ajaksu2, pitrou

messages: + msg87713

stage: patch review
2008-01-06 22:29:45adminsetkeywords: - py3k
versions: Python 3.0
2007-11-08 15:01:57christian.heimessetpriority: normal
keywords: + py3k
type: behavior -> enhancement
2007-09-25 18:29:27gvanrossumsetmessages: + msg56138
2007-09-25 17:24:19gvanrossumsetnosy: + gvanrossum
messages: + msg56136
2007-09-25 05:25:31jyasskincreate