3 ms·
It's interesting to see how different people's complaint lists can be. I have my own list for Python (e.g., mutable/immutable/reference semantics/blah blah blah
by ggchappell 16y ago
It's interesting to see how different people's complaint lists can be. I have my own list for Python (e.g., mutable/immutable/reference semantics/blah blah blah stuff messes me up all the time), but my list has almost nothing in common with the one in this article.
In particular, I've thought about the first issue -- range specifications -- off & on for years, and I've come to the conclusion that this writer is wrong; Python does ranges the right way. The crux of the matter, for me, is that sometimes includes-the-end feels right, and sometimes does-not-include-the-end feels right. However, sometimes includes-the-end is definitely wrong, but I don't know of any case where does-not-include-the-end is definitely wrong. So if you're going to pick one convention, then go with the one Python did; use it all the time, and you'll never have to wonder which one you're using. It is true that this convention takes some getting used to, but I think it results in fewer bugs in the long run.
Other advantages: b - a is the number of items in range(a,b); also range(a,b) and range(b,c) partition range(a,c) nicely.
BTW, I believe E. Dijkstra has an essay that also takes this position on range specifications; he probably explained it a lot better than I did.
As for Unicode, no one seems to know how to do it well. But this writer is talking about the Python 2 way of doing things. Python 3 has improved things, IMHO.
- baddox 16y agoThis Dijkstra essay touches on the topic. http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD08x...
- ggchappell 16y agoThat's the one I was thinking of. Thanx.
- barrkel 16y agoRange as [a, b) is definitely one of the best ways of thinking about them in the context of most algorithms. b-a is reliably the length; and when you choose a midpoint m, [a, m) and [m, b) don't overlap. Thinking in these terms makes implementing e.g. quicksort and binary search much easier.
- nailer 16y agoMy math is rusty. Could you explain your use of square and regular brackets in [a, m) and [m, b) ?
- alan-crowe 16y agoThe common useage in mathematics is in analysis and topology, to specify subsets of the real numbers. Remembering that open and closed are jargon terms in topology: (a,b) is an open set and contains exactly those x such that a is less than x and x is less than b. [a,b] is a closed set and contains exactly those x such that a is less than or equal to x and x is less than or equal to b For example, one might be thinking about the interval [0,pi] but the function 1/sin x has singularities at both ends of the interval. It is only defined on (0,pi). Notice that 1/x is defined on (0,pi]. It is sometimes convenient to mix up open=exclusive=() and closed=inclusive=[]. These conventions can be carried over into computer science in the obvious way [0,3) = {0,1,2} while (0,3] = {1,2,3} but the motivation is different. In computer science we are more concerned how smoothly our subranges chain together. For example [0,r)+[r,s)+[s,t) = [0,t) while [0,r]+[r+1,s]+[s+1,t] = [0,t]