On Dec 12, 2019, at 11:21, Jonathan Fine <[email protected]> wrote: > > > (We're still a bit off-topic here.) You asked me what I'd expect, if not the > present values of: > > >>> seq[] > SyntaxError: invalid syntax > > >>> getslice[1:2:3:4] > SyntaxError: invalid syntax > > I'd have expected to got respectively the outcome of > > >>> seq.__getitem__() > >>> seq.__getitem__(slice(1, 2, 3, 4)) > > In other words, a run-time error rather than a syntax error.
For the first one, why isn’t it an empty slice, or an empty tuple, instead of no argument? The syntax is ambiguous between all three. And the fact that people on this thread have already suggested they’d like the empty tuple, while you’d like nothing, looks like good evidence that it’s ambiguous to people, not just parsers. For the second one, though, on reflection that would make perfect sense. Making the parser handling one or more colons instead of one or two colons shouldn’t be a problem. And it’s probably only because of historical reasons (Python used to have __getitem__(a) for [a] and __getslice__(a,b) for [a:b], and there were no three-item slices or tuples or ellipsis or anything) that it’s handled the way it is. If we’d always got a “TypeError: slice expected at least 1 argument, got 0” and someone pointed out that we could trivially detect this at compile time and raise a SyntaxError instead, would people go for that, or argue that there’s no need, because catching things at runtime is fine everywhere else in Python? I think the latter. But, that being said, arguing that there’s a need to _undo_ that is just as hard as arguing that there’d be a need to _do_ it would have been. It’s good enough either way, so just keep doing the one we’ve been doing. [snip] > And this would perhaps open the door to > > >>> seq[0, 1, key=3] > > no longer being a SyntaxError. How? There’s no slices there at all, there’s a tuple with non-slice elements, and surely however you want to handle keywords, they’re an extension to tuple syntax, not slice syntax. (Unless you want to allow key:value=1:3 or something?) Anyway, I think if I were designing a language from scratch, I’d get rid of all the sugar on indexing. seq[0, 1, key=3] is just seq.__getitem__(0, 1, key=3), and seq[1:2, ..., 3, 4:-3:-1] is just seq.__getitem__(1:2, ..., 3, 4:-3:-1]. And that means 1:2 has to be a valid expression on its own, but why not? Maybe I’d spell it 1..2 (and then 1...2 means a closed slice rather than a half-open one). Then merge slices with ranges. (What is the range “eggs”:”spam”? It’s a range you can use to slice a sorteddict, but if you try to iterate it or contains it you get a ValueError.) Now we’ve got something as convenient to use as Python, and more convenient for people implementing sequence and mapping types (no more “if it’s a tuple do this, else do that”, it’s just always *args, as it should be), and more flexible. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ES2LOLKVI3TUESTRYIH4V7H5FPAVZX2C/ Code of Conduct: http://python.org/psf/codeofconduct/
