Tim Peters <[EMAIL PROTECTED]> writes: > > Huh? [1,2,[3,4,5],[6,[[[[7]],8]]]] is a perfectly valid Python list. > > You're claiming not to know any relevant difference between Python > lists and Lisp lists? Heh.
Python doesn't provide syntactic sugar for [1,[2,[3,[4,[]]]]] if that's what you mean. In Lisp you'd say (1 2 3 4). It's still a perfectly valid list in Python. Python by convention uses multi-element arrays instead of lists of conses. > > And you can break out of a containing loop from a nested loop > > with try/raise. > > Heh heh. Yes, you can. I've never seen a real Python program that > did, but there's nothing to stop you. I do that on a fairly routine basis. I won't say "often", but it's a standard technique that finds a use now and then. > What did you think the "direct" in "direct way" might have been > intended to mean? I guess you meant there's no syntax sugar for a multi-level break or a break with a label. It hasn't been that big a problem. C doesn't have it either. The need for it comes up infrequently enough that try/except is a satisfactory way to handle it. > > More troublesome is not being able to see a variable in a > > containing scope from a nested scope, unless the containing > > scope is the global one. Why bother debating lexical scope for > > years before deciding to add it, only to stop halfway? > > I'd call it 80% of the way, but suit yourself. The debates are all > easily found, if you really want to know. Well, I'd say whatever the percentage is, it started at near zero and has been slowly increasing and continues to increase. For example, [x*x for x in range(5)] doesn't create a temporary scope but (x*x for x in range(5)) does, and [x*x for x in range(5)] will apparently do so in a future version. There's a technique in numerical analysis called Richardson extrapolation, where you compute an integral by evaluating the function at n=k points, then at n=2k points, then at n=4k points, etc. and fit a curve through these approximations to estimate the limit at n=infinity. This turns out to be a good way to compute integrals. Basically by making a few better and better approximations at the answer, you can make a good estimate of the final result you'd get if you kept approximating forever. I see the same thing happening in Python. It's going through successively better approximations to get closer to a limit. Python has it harder than some other languages, because it tries to serve the needs of both throwaway scripts and large-scale development projects. The result is that feature after feature starts out with an implementation sufficient for small scripts, and then edges towards the needs of large-scale projects. But it's often predictable at the beginning what the final destination is going to be. So once we can see where it's going, why not proceed to the finish line immediately instead of bothering with the intermediate steps? -- http://mail.python.org/mailman/listinfo/python-list