Re: [Python-ideas] Python reviewed
Oh one last thing (I hope), the argument for having the current slice notation by Dijkstra, that it looks messy to have a loop where the contents are never executed or can no longer be executed is ridiculous! That *should* look messy. for range(1,1): means executing once to me. If you had 1 based, two of four of the other idioms would work the same: s[:n] + s[n:] == s // doesn't work. I don't think it should work though len(s[:n]) == n // works len(s[:-n]) == n // rather independent but would still work if language is otherwise unchanged. len(s[n:i]) == i - n // doesn't work. Does it need to? Rgds
for range(1,1): means executing once to me. The indexing/slicing approach was designed for indexing and slicing. Then it made sense to have range() match. But range() is not part of the for construction. It is a convenience function for providing an iterable of integers. And you are welcome to write your own range-like iterable if you want. But if you want to look once, you'd use range(1), not range(1,2) anyway. Clear as day. And if you use: range(n, n+I), it is very clear that you will loop i times. s[:n] + s[n:] == s // doesn't work. I don't think it should work though Have you ever used a 1-based and closed-end indexing language that supported slicing? I have (matlab), and these kinds of constructions are really ugly and prone to error. It's not that you want to be able to divide a sequence and immediately put it back together, it's that you often want to do one thing with the first part of a sequence, and another with the second part, and you don't want them to overlap. len(s[:n]) == n // works len(s[:-n]) == n // rather independent but would still work if language is otherwise unchanged. len(s[n:i]) == i - n // doesn't work. Does it need to? It's not that it HAS to - it's that it's much less likely that you will make off by one errors if it does. -CHB
for range(1,1): means executing once to me. The indexing/slicing approach was designed for indexing and slicing. Then it made sense to have range() match. But range() is not part of the for construction. It is a convenience function for providing an iterable of integers. And you are welcome to write your own range-like iterable if you want. But if you want to look once, you'd use range(1), not range(1,2) anyway. Clear as day. And if you use: range(n, n+I), it is very clear that you will loop i times. s[:n] + s[n:] == s // doesn't work. I don't think it should work though Have you ever used a 1-based and closed-end indexing language that supported slicing? I have (matlab), and these kinds of constructions are really ugly and prone to error. It's not that you want to be able to divide a sequence and immediately put it back together, it's that you often want to do one thing with the first part of a sequence, and another with the second part, and you don't want them to overlap. len(s[:n]) == n // works len(s[:-n]) == n // rather independent but would still work if language is otherwise unchanged. len(s[n:i]) == i - n // doesn't work. Does it need to? It's not that it HAS to - it's that it's much less likely that you will make off by one errors if it does. -CHB
participants (2)
-
Chris Barker - NOAA Federal -
Simon Lovell