Collections of non-arbitrary objects ?

[Bruno Desthuilliers]

walterbyrd a écrit :
>>> On Jun 24, 10:31 pm, Bruno Desthuilliers
>>> <bdesth.quelquech... at free.quelquepart.fr> wrote:
>> 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.