walterbyrd a écrit : >>> 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.
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. -- http://mail.python.org/mailman/listinfo/python-list
