I hadnt thought of that, but its kind of elegant.
for i in (a:b:c:d:e):
Would probably be an error. Trying to make an iterator out of anything
but a 2 or 3 element slice should fail, unless you supply your own
iterator factory.
Omitted slice elements being None is a nice idea, and would work with
the RDF notation
(subj::obj) -> slice(subj, None, obj)
It gets a little hairy when you start doing things like this, however
(::) -> slice(None, None, None)
And what then of the 1-element slice? (if its necessary at all)
(1:) -> slice(1, None) or slice(1)??
> -----Original Message-----
> From: Alex Martelli [mailto:aleax@aleax.it]
> Sent: Thursday, 2 May 2002 02:39
> To: Damien Morton; python-dev@python.org
> Subject: iterable slices
>
>
> On Thursday 02 May 2002 08:04, Damien Morton wrote:
> ...
> > Could the notation a:b:c:d:... be generalised, with
> slices becoming a
> > kind of tuple. For backwards compatability, the first three
> elements
> > of the tuple could be accessed using the start, stop, step
> attributes.
> ...
> > {1, 2, 3} -> dict([slice(1), slice(2), slice(3)]}
> >
> > A slice on its own would be writen:
> >
> > (1:2:3) -> slice(1,2,3)
> >
> > A 1-element slice might be written similarily to a 1-element tuple:
> > (1:) -> slice(1)
>
> And presumably None could be omitted, e.g. (:1) as slice(None,1).
>
> Related but somewhat orthogonal to this idea -- I'm starting
> to think that slices should be iterable, with
> iter(slice(a,b,c)) yielding exactly the same numbers as
> iter(range(a,b,c)) or iter(xrange(a,b,c)). If any such
> abbreviated notation existed for slices, then "for i in
> (:6):" might work. Risks: perhaps error-prone ("for i in
> {:6}:", "for i in (6:):", etc, might be likely typos yielding
> unexpected behavior); no idea of what behavior would be
> expected of "for i in (a:b:c:d:e):".
>
>
> Alex
>
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