Open GoogleCodeExporter opened 8 years ago
(And thanks google code for not letting me edit the issue description.)
I obviously like what I've suggested, I could think of a handful of reasons
against this though:
* It doesn't yield the most readable code... and the unclear operator precedence of : and , does not help, i.e. g[me,:RDF.type,RDFS.label] vs. g[me,:(RDF.type,RDFS.label)] (one means, give me the type AND label of all things the resource "me" is linked to, the other says give me the type, then the label of the type)
* Python in general is moving AWAY from special syntax, like % for string formatting disappearing in py3.
* The pythonic commandment, there should be one way and one way only to do it - this is another way of doing much the same as triples, subject_predicates, etc.
Original comment by gromgull
on 15 Jan 2012 at 2:47
I suggest that, if we do this, it's limited to quite a simple interface, and
people are forced to explicitly call methods for more complex tasks. I would
avoid trying to make some sort of mini-language from slices, because it would
be very hard to read.
At a glance, without having tried to use it, the idea of interpreting a single
slice object as subj:pred:obj is quite attractive. I would limit it to
accepting a single slice, and allow tuples meaning only 'discjunction' (I'd
describe it as 'union', following the terminology for sets).
Pythonic-ness: It's a minor abuse of slice notation, but we're still retrieving
a subset of items from a collection.
Side note: % for string formatting is still there in py3. It was officially
'deprecated', but I don't think anyone's too keen to remove it.
One-way-to-do-it: I suggest the docs describe it as a convenience feature, for
interactive work or quick scripts, and encourage people to use explicit method
calls in software that is to be maintained.
Original comment by tak...@gmail.com
on 15 Jan 2012 at 3:29
Original issue reported on code.google.com by
gromgull
on 15 Jan 2012 at 2:42