> > On Jun 24, 10:31 pm, Bruno Desthuilliers > > <[EMAIL PROTECTED]> 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
