Collections of non-arbitrary objects ?

[walterbyrd]

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?

[Larry Bates]

walterbyrd wrote:

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a collection
of non-arbitrary objects? A list of records, or something like that?

Code the record as an object (class) and place instances of those objects inside
a list or dictionary (depending on access required). Or if you don't want to do
much with the records just put each instance of a record (normally a record is
implemented as a tuple at least thats how SQL databases return rows) inside a
list or a dictionary (again depending on access required).

-Larry

[bruno.desthuilliers]

On Jun 21, 8:19 pm, walterbyrd <walterb...@ina me.comwrote:

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries.

And sets.

But what if I want a collection
of non-arbitrary objects?

Then only put the kind of objects you want in the collection.

A list of records, or something like that

'Records' can be implemented as tuples, dicts or using a custom class.

[Ben Finney]

walterbyrd <wa********@ina me.comwrites:

Python seems to have a log of ways to do collections of arbitrary
objects: lists, tuples, dictionaries. But what if I want a
collection of non-arbitrary objects? A list of records, or something
like that?

Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the question. What
are you asking for that you don't already have? A list can contain a
sequence of objects of the same type already. What are you expecting
that a list does not provide?

--
\ "Faith may be defined briefly as an illogical belief in the |
`\ occurrence of the improbable." -- Henry L. Mencken |
_o__) |
Ben Finney

[Grant Edwards]

On 2007-06-21, Ben Finney <bi************ ****@benfinney. id.auwrote:

walterbyrd <wa********@ina me.comwrites:

>Python seems to have a log of ways to do collections of
arbitrary objects: lists, tuples, dictionaries. But what if I
want a collection of non-arbitrary objects?

Lists never contain arbitrary objects, they contain only
objects that you put there. The reason that other languages
have typed containers (e.g. array of type T) is that the
elements of the array don't know what type they are, so you've
got to limit what you put in there. In python, all objects
know what type they are, so there's no point in labelling the
references to the objects with type info as well.

>A list of records, or something like that?

Then collect them in a non-arbitrary way.

That's a flippant response, but I don't understand the
question. What are you asking for that you don't already have?
A list can contain a sequence of objects of the same type
already. What are you expecting that a list does not provide?

I was also a bit baffled by the question. The only things I
could think of are:

1) a "container" that raised an exception if the type of a new
item doesn't match the type of what's in it already. I
don't really see much benefit in that. If you want a list
to contain only objects of type T, then only put that type
of objects in it.

2) an "array" that contains a large number of small things
(e.g. integer or floating point numbers) that need to be
stored with minimal overhead. That's a useful thing, and
there are several packages that do that -- numpy is the one
generally recommended for new designs.

--
Grant Edwards grante Yow! Are the STEWED PRUNES
at still in the HAIR DRYER?
visi.com

[walterbyrd]

On Jun 21, 5:38 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

That's a flippant response, but I don't understand the question.

Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.

[Ben Finney]

walterbyrd <wa********@ina me.comwrites:

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

--
\ "Quidquid latine dictum sit, altum viditur." ("Whatever is |
`\ said in Latin, sounds profound.") -- Anonymous |
_o__) |
Ben Finney

[Gabriel Genellina]

En Fri, 22 Jun 2007 21:45:02 -0300, walterbyrd <wa********@ina me.com>
escribió:

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Sure. You can implement it yourself, if you want; it's not so hard even
for a beginner. It's just not needed enough, or required enough, to become
a builtin type.
Look for some recent posts about a RestrictedList.

--
Gabriel Genellina

[Paddy]

On Jun 23, 1:45 am, walterbyrd <walterb...@ina me.comwrote:

On Jun 21, 5:38 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

That's a flippant response, but I don't understand the question.

Everybody here seems to have about the same response: "why would you
ever want to do that?"

Maybe it's something that doesn't "need" to be done, but it seems to
me that would give you a certain level of built-in integrity - you
could be sure about what's in the structure. I would not expect that
all of python would be that rigid, but I thought it might be
worthwhile if there were one such structure.

Think of this: why use tuples when lists are available? You can use a
tuple to index a dictionary, but not a list - why? I the answer may
be that sometimes you want some degree on inherent enforced structure.
I'm sure the language could have designed to allow lists to index
dictionary, but you would have to awfully careful with those lists.
The burden would be on the programmer to make certain that those lists
didn't change. But, it could be done, therefore tuples are not
"needed" right?

Languages like C are often criticized as being too rigid - you have to
pre-define your variables, and pre-allocate your array sizes. But,
languages like Perl and BASIC, are often criticized as being to
sloppy - too few restrictions tend to lead to sloppy code. So I guess
there is a sort of trade-off.

I suppose I could use a database, that might give me some degree of
assured integrity - depending on what database I used.

Hi Walterbyrd,
What happens when you are given good advice that may be contrary to
intuition?

Unfortunately its how we usually do things in Python and do NOT
suffer because of it. Try writing your application without it. Test
without it. Write other applications without it. Others do,
successfully.

- Paddy.

[walterbyrd]

On Jun 22, 11:43 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

Can you help us understand, by showing a use case that would in your
estimation be improved by the feature you're describing?

Suppose you are sequentially processing a list with a routine that
expects every item to be of a certain type. Something in the list that
doesn't conform to the type could give you unexpected results, maybe
crash your application.

In python, as far as I know, there is nothing built into the language
to keep any type of item from being included in a list - or any such
structure. To me, that seems like a potentially vulnerability.
Especially since variables in python do not have to be explicitly
assigned - another variable that points to the same thing, could
change the data that a variable points to.