Implicit lists

[Bengt Richter]

On 31 Jan 2003 18:38:55 +0100, Thomas Heller <theller at python.net> wrote:

>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.
>
A container can be a single object for some purposes, so purpose
has to be involved in the decision. Unfortunately that tends to
involve the universal DWIM function ;-) If the purpose of an
object is to act like a container only in the aspect of being
able to produce a series of objects, you can't infer anything
about the type of the objects you will get or how they were
produced. Or else "container" has to be a pretty narrow concept.

>Only Python strings are a problem here, so IMO a stringlike
>test like Alex suggested is what is wanted.
IMO using a particular behaviour probe to infer general behavior
and/or type info is fraught with pitfalls. E.g., that innocent '+'
in Alex's probe changes the question from "will you act like a string"
to "do you implement '+' with the other arg specifically being "''"
without raising an exception. It is not the same question. Not to
mention what an unknown object might do in terms of side effects
and/or execution time when probed.

I think there is more thinking to do ;-)

Regards,
Bengt Richter