I was reading TBLs presentation of webizing Python, and specifically his ideas about incorporating RDF into the syntax of Python. The recent thread on slice notation, and some of my experiences playing around implementing syntax for TBLs RDF-in-Python proposal got me thinking. 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. Could the dictionary notation be related to slice notation, such that a dictionary is defined as being an object initialised by a list of slices. { 1:2, 3:4 } <--> dict([slice(1,2), slice(3,4)]) For RDF notation, you could then happily write: {1:2:3, 4:5:6, 7:8:9} --> dict([slice(1,2,3), slice(4,5,6), slice(7,8,9)]) For sets, you would write: {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)
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
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
On Thursday 02 May 2002 09:05, Damien Morton wrote: ...
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.
Currently you can't "supply your own factory" between iter() and a given object type -- iter() looks for the object's __iter__ (&c), not in any registry of adapter-factories. PEP 246 might be tweaked to change that, but it would be a doubtful change IMHO.
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)
You could forbid it:
slice() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: slice() takes at least 1 argument (0 given)
And what then of the 1-element slice? (if its necessary at all)
It definitely is (to indicate "all items from i" or "all items up to i", depending on which 'element' you mean, start or stop).
(1:) -> slice(1, None) or slice(1)??
slice(3) slice(None, 3, None)
i.e., like (:3). (1:) must clearly mean "all from 1 upwards" by analogy with sequence slicing such as somelist[1:]. Alex
slice(3) slice(None, 3, None)
This is where it breaks down. You'd have to do some buggering around with the start/stop/step attributes to make it work. There wouldn't be a direct correspondance between the slice/tuple element positions and the start and stop attributes. a = slice(3) a[0]==3, a.start==None, a.stop==3, a.step==None b = slice(1,3) b[0]==1, b[1]==3, b.start=1, b.stop=3, b.step=None By supplying your own factory I was thinking of something like the range() function. for i in weirditer(a:b:c:d:e): Probably not very usefull, given that you can already do that without having to resort to slices. for i in weirditer(a,b,c,d,e): Since lists happily deal with empty slices [1,2,3,4,5][:], I don't see any reason why youd forbid them at higher (or lower) dimensions. The issue with something like: (::) Is the line-noise quality of it. Its not too bad though. You can push this idea into the realms of the extremely strange by imagining nested slices and slices of tuples and such. (1:(2:3:(1,2,3)):("hello",f(y)))
-----Original Message----- From: Alex Martelli [mailto:aleax@aleax.it] Sent: Thursday, 2 May 2002 03:21 To: Damien Morton; python-dev@python.org Subject: Re: [Python-Dev] RE: iterable slices
On Thursday 02 May 2002 09:05, Damien Morton wrote: ...
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.
Currently you can't "supply your own factory" between iter() and a given object type -- iter() looks for the object's __iter__ (&c), not in any registry of adapter-factories. PEP 246 might be tweaked to change that, but it would be a doubtful change IMHO.
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)
You could forbid it:
slice() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: slice() takes at least 1 argument (0 given)
And what then of the 1-element slice? (if its necessary at all)
It definitely is (to indicate "all items from i" or "all items up to i", depending on which 'element' you mean, start or stop).
(1:) -> slice(1, None) or slice(1)??
slice(3) slice(None, 3, None)
i.e., like (:3). (1:) must clearly mean "all from 1 upwards" by analogy with sequence slicing such as somelist[1:].
Alex
Damien Morton <Damien.Morton@acm.org>: [snip]
{ 1:2, 3:4 } <--> dict([slice(1,2), slice(3,4)])
For RDF notation, you could then happily write:
{1:2:3, 4:5:6, 7:8:9} --> dict([slice(1,2,3), slice(4,5,6), slice(7,8,9)])
Hm. Is it really necessary to invent a new notation for this? The link between these tuple-like structures (e.g. 1:2:3) and slices seems tenuous and very confusing to me. If we're not going with the W3C XML notation, why not use a more Pythonic one? Assuming that we'll eventually get sets, should the Python-RDF-notation simply be a set of 3-tuples? E.g: {(1, 2, 3), (4, 5, 6), (7, 8, 9)} -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org
participants (3)
-
Alex Martelli -
Damien Morton -
Magnus Lie Hetland