theller at python.net
Fri Jan 31 18:38:55 CET 2003
Christian Tismer <tismer at tismer.com> writes:
> Thomas Heller wrote:
> > Christian Tismer <tismer at tismer.com> writes:
> [iscontainer implementation using buffer interface]
> >>I'm (ab)using the fact that sequences which are
> >>no containers usually support the buffer interface.
> > This is worse, IMO.
> > ctypes' instances support the buffer interface, whether
> > they are sequences (or containers) or not.
> After second thought, this is not worse, but great!
> Nobody wants to see ctypes instances to be
> used as containers for multiple arguments.
> This is the domain of relatives of lists and tuples
> and other, "plain Python" types.
> Is there an object in ctypes which is meant as
> a candidate for this domain? If not, then the
> buffer approach is not so bad.
Sure, something very similar to array.array('i'),
but with fixed length.
The way I see it, this is a container for integers,
but stored more efficiently maybe, and 'meaningful'
to C code at the same time.
> A buffer means something to access the interior
> of an object, which means that the object has
> some flat memory somewhere. If you support
> buffer, I think you say you are not a container.
No, I don't think so. 'buffer' only says something
about the internal implementation of the object.
Being able to iterate over array.array instances, for
example, is really useful. Image you would always
have to convert it to a list or tuple before.
> Even if this is cheating, I'd take this as honest
> and won't take you as a parameter list. :-)
Back to the original problem, the OP wanted to decide
IIRC if he's got a single object, or a container.
Only Python strings are a problem here, so IMO a stringlike
test like Alex suggested is what is wanted.
More information about the Python-list