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?

[Marc 'BlackJack' Rintsch]

In <46************ ***********@new s.free.fr>, Bruno Desthuilliers wrote:

walterbyrd a écrit :

>For example, I don't think you can divide a string by another string.

No, because this operation is not implemented for strings - IOW, strings
doesn't understand this message. What would be the meaning of dividing
strings anyway ? (while concatening string is a well-known operation).

As someone else already mentioned dividing strings is splitting. The Pike
language does this:

http://pike.ida.liu.se/generated/man...chapter_4.html

Scroll down to ``string / string``. The definition of ``string / float``
is neat too. Something I really miss in everyday programming in Python,
not. ;-)

Ciao,
Marc 'BlackJack' Rintsch

[Ben Finney]

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

>a = [1,2,3]
b = a
a[1] = 'spam'

Here, I have changed b, without an explicit assignment.

No. Both 'a' and 'b' are names bound to a single object; you're
changing that object. This is a subtle difference, but it's one that
is confusing you in this instance.

So let's say I have list L, and I have a routine that expects every
item in L to be a dictionary like: {'name':'joe', 'job':'dev',
'pay': min_wage}.

If that routine expects objects of a particular *type*, instead of
objects that exhibit expected *behaviour*, the routine is poorly
designed.

Not only could the app crash if an incorrect item where inserted
into L. But the app could crash if an incorrect item were inserted
in lists X,Y, or Z.

When the routine tries to deal with an object that doesn't behave as
expected, an exception will be raised. If the exception goes uncaught,
then Python will exit and throw the exception to the user; I suppose
you could call this a "crash".

Of course, you can always work around this by just programming very
carefully, and doing a lot of error checking. That is always true in
any language.

Better is to catch the exception at a level where it can be dealt
with; this is usually the same level where those non-conforming
objects were placed in the list to begin with.

BTW: I think polymorphism is great and all. But it does have (and
IMO should have) it's limitations. For example, I don't think you
can divide a string by another string.

Indeed, and you'll get an exception raised if you try. Catch that
exception at a level where there's enough context to make sense of it,
and deal with it in whatever way you see fit.

--
\ "Imagine a world without hypothetical situations." -- Anonymous |
`\ |
_o__) |
Ben Finney

[Paul Rubin]

Bruno Desthuilliers <bd************ *****@free.quel quepart.frwrite s:

You know, Python is now something like 17 years old, and is used by a
*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you
seem to fear so much will not happens that often.

Assembler and Cobol have been around even longer...

[Gabriel Genellina]

En Mon, 25 Jun 2007 11:14:23 -0300, walterbyrd <wa********@ina me.com>
escribió:

I have probably expressed this incorrectly. What I meant was:

>>>a = [1,2,3]
b = a
a[1] = 'spam'

Here, I have changed b, without an explicit assignment. After I
assigned a to b, I never did another "b =" yet b changed anyway
because I changed a. I am not saying there is anything wrong with
this, I'm just explaining what I meant.

I think you should benefit reading this short article:
http://effbot.org/zone/python-objects.htm

--
Gabriel Genellina

[Michele Simionato]

On Jun 25, 8:21 pm, Marius Gedminas <mged...@gmail. comwrote:

On Jun 24, 2:12 pm, Bjoern Schliessmann <usenet-

mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

7stud wrote:

if hasattr(elmt, some_func):
elmt.some_func( )

Personally, I prefer

try:
elmt.some_func( )
except AttributeError:
# do stuff

That also hides attribute errors that occur within some_func. I think
I'd rather know when elmt has an implementation of some_func that is
buggy. Thus I prefer the hasattr version.

Or possibly

try:
do_func = elmt.some_func
except AttributeError:
do_stuff()
else:
do_func()

(internally hasattr is doing that anyway).

Michele Simionato

[walterbyrd]

On Jun 24, 10:31 pm, Bruno Desthuilliers

<bdesth.quelque [e-mail] quepart.frwrote :

You perhaps don't know this, but most statically typed languages have
the notion of either pointers or references, that can cause similar -
and usually worse - problems.

Yes, but those languages also have the notion of structures that do
not allow arbitrary collections. That is what I was wondering about
when I started the thread. It's fine that python has four different
ways of creating collections of arbitrary data types, but I thought it
might be helpful if python had, at least, one way of a creating a
collection of non-arbitrary data.

>
You do program carefully, don't you ?-)

I try. But things like typos are a normal part a life.

>
Now did you actually had any effective problem with Python's dynamism ?
Or are you just scared ?

Just scared.

You know, Python is now something like 17 years old, and is used by

a

*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you seem
to fear so much will not happens that often.

Of course, BASIC is over 40 years old, also used by a *lot* of people.
A lot of non-trivial apps have been written in BASIC. But, BASIC is
often criticized for it's lack of structure. A language's longevity,
and/or popularity, don't mean there isn't room for improvement. Guido
must think python has a lot of room for improvement since he's
completely throwing out backward compatibility with python 3000.

>
You don't use tuples "instead of" lists. Lists are collections, tuples
are structured data.

It seems to me that tuple are essentially immutable lists. So why
impose that immutability restriction on a data collection? Why not
just have lists and not tuples? What can a tuple do that a list can
not do? Why was python designed so that tuples could be used for
dictionary indexes, but not lists? Could it be because imposing that
restriction on a data collection insures a certain degree of
integrity? My point is: sometimes imposing some restrictions can give
a degree in built-in integrity. Maybe you don't need that integrity
insurance, if you code carefully enough, but can you always count on
that?

BTW: I'm not assuming that it will always be me running my own app.
Sure, if an exception occureed while I was running my own app, I'd
probably know what to do. But if somebody else (who - god forbid -
didn't know python was running the app, things might be more difficult.

[Bruno Desthuilliers]

walterbyrd a écrit :

>>On Jun 24, 10:31 pm, Bruno Desthuilliers
<bdesth.quelq [e-mail] elquepart.frwro te:

You perhaps don't know this, but most statically typed languages have
the notion of either pointers or references, that can cause similar -
and usually worse - problems.

Yes, but those languages also have the notion of structures that do
not allow arbitrary collections.

Ever played with casting in C ?

That is what I was wondering about
when I started the thread. It's fine that python has four different
ways of creating collections of arbitrary data types, but I thought it
might be helpful if python had, at least, one way of a creating a
collection of non-arbitrary data.

As I explained, while technically possible (and not specially
difficult), this is a waste of time given Python's dynamism.

>You do program carefully, don't you ?-)

I try. But things like typos are a normal part a life.

So are they in any language. I fail to see much difference here.

>Now did you actually had any effective problem with Python's dynamism ?
Or are you just scared ?

Just scared.

So take a deep breath and try to just do the simplest thing (in this
case: using builtin collection types). Usually, it JustWorks(tm).

You know, Python is now something like 17 years old, and is used by

a

>*lot* of peoples for a *lot* of programs - some of them far from
trivial. I think you can be confident in this experience. IOW, just
write your code, and you'll find out that the kind of problems you seem
to fear so much will not happens that often.

Of course, BASIC is over 40 years old, also used by a *lot* of people.

Not the same kind of people I'd say !-)

A lot of non-trivial apps have been written in BASIC. But, BASIC is
often criticized for it's lack of structure.

Old time basic effectively lacks of "structure" , since it uses goto's
instead of functions, loops and conditionals (google for "structured
programming").

What I meant here is that one of the lessons of this collective
experience is that 'typed' containers are more often harmful than useful.

A language's longevity,
and/or popularity, don't mean there isn't room for improvement.

Indeed. But declarative static typechecking wouldn't be an improvement.

Guido
must think python has a lot of room for improvement since he's
completely throwing out backward compatibility with python 3000.

Not "completely throwing out". Just allowing *some* major breakages -
the kind you usually get with each major release of other languages, but
that Python managed to avoid as much as possible so far.

>You don't use tuples "instead of" lists. Lists are collections, tuples
are structured data.

It seems to me that tuple are essentially immutable lists.

They are not (even if you can use them that way too). FWIW and IIRC,
this is a FAQ.

So why
impose that immutability restriction on a data collection?

Because tuples are *not* collections. They are *structured data*. The
canonical tuple is a SQL database row.

Why not
just have lists and not tuples?

because tuples are not lists.

What can a tuple do that a list can
not do?

Be immutable.

Why was python designed so that tuples could be used for
dictionary indexes, but not lists?

How would you compute a hash from a generic mutable collection ?

Could it be because imposing that
restriction on a data collection insures a certain degree of
integrity?

Once again: tuples are *not* collections. Would you define a string as a
collection ?

My point is: sometimes imposing some restrictions can give
a degree in built-in integrity.

Yes. But the kind of restriction you're talking about won't buy you
much, as I already explained, and, in practice, happens to be mostly
useless.

Maybe you don't need that integrity
insurance, if you code carefully enough,

Maybe you don't need that "integrity insurance", period ?-)

but can you always count on
that?

It seems that tens of thousands of Python users are doing fine without this.

BTW: I'm not assuming that it will always be me running my own app.
Sure, if an exception occureed while I was running my own app, I'd
probably know what to do. But if somebody else (who - god forbid -
didn't know python was running the app, things might be more difficult.

The canonical solution is to have an application-level error handler
that logs uncaught exceptions (so the developper can get at them),
display a user-friendly error message (eventually giving the user a way
to submit a bug report to the developper), and try to crash as cleanly
as possible.

However careful and serious you are wrt/ programming and testing, your
program *will* have bugs (unless it's some kind of hello world). Better
learn to live with it.

Let's suppose you implement a restrictedList. It of course raises an
exception when trying to add a 'non-compliant' item. All this happening
at runtime, of course. Now let's suppose there's one such error in your
code that managed to pass thru tests. What's going to happen ? Yes,
exactly the same thing as if you used a plain list - just somewhere else
in the code. For the final user, the result will be *exactly* the same :
a crash.

[walterbyrd]

>

Did you try to sort a tuple ?

>>(1, "aaa").sort ()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'tuple' object has no attribute 'sort'

I can do this:

>>x = (3,2,1)
x = tuple(sorted(li st(x)))

Which, although senseless, effectively sorts the x tuple. But, you are
right, I am not really sorting the tuple, I'm sorting a list, which
has been made from the tuple, then changing it back to a tuple.

Actually, I can even do it in one line:

x = tuple(sorted(li st((3,2,1))))

[Peter Otten]

walterbyrd wrote:

I can do this:

x = tuple(sorted(li st((3,2,1))))

The list() conversion is superfluous:

>>tuple(sorted( (3,2,1)))

(1, 2, 3)

Peter