tim peters wrote:
> Charles likes slices. Me too! I *love* them. But as a standalone notation
> (i.e., not as a subscript), part of the glory of slicing breaks down: for
> the list a, a[:] makes good sense, but when *iterating* over a, it's
> suddenly [:len(a)] because there's no context to supply a correct upper
> bound.
agreed. ranges and slices are two different things. giving
them the same syntax is a lousy idea.
> Post 2.0, who knows. I'm not convinced Python actually needs another
> arithmetic-progression *list* notation. If it does, I've always been fond
> of Haskell's range literals (but note that they include the endpoint):
>
> Prelude> [1..10]
> [1,2,3,4,5,6,7,8,9,10]
> Prelude> [1, 3 .. 10]
> [1,3,5,7,9]
isn't that taken from SETL?
(the more I look at SETL, the more Pythonic it looks. not too
bad for something that was designed in the late sixties ;-)
talking about SETL, now that the range literals are gone, how
about revisiting an old proposal:
"...personally, I prefer their "tuple former" syntax over the the
current PEP202 proposal:
[expression : iterator]
[n : n in range(100)]
[(x**2, x) : x in range(1, 6)]
[a : a in y if a > 5]
(all examples are slightly pythonified; most notably, they
use "|" or "st" (such that) instead of "if")
the expression can be omitted if it's the same thing as the
loop variable, *and* there's at least one "if" clause:
[a in y if a > 5]
also note that their "for-in" statement can take qualifiers:
for a in y if a > 5:
...
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4