Negative array slice steps in Proposal A about json-path-comparison

[cburgmer]

There is no consensus for ["first", "second", "third", "fourth", "fifth"][3::-1] so far, but certainly a "productive" majority (as in non-empty responses) for the Python way: https://cburgmer.github.io/json-path-comparison/results/array_slice_with_open_end_and_negative_step.html

[cburgmer]

For me the best argument so far was "follow what Python is doing". For many developers that would probably be the least surprise. If we have another widely adopted implementation out there then let's put it on the table.

[glyn]

Unfortunately, those old 2.0 docs are silent about what happens when stride < 0. Experimentally, Python 3 seems to adopt the "forwards A" interpretation:

$ python3
>>> ["first", "second", "third", "fourth", "fifth"][3:0:-1]
['fourth', 'third', 'second']
>>> ["first", "second", "third", "fourth", "fifth"][3:-1:-1]
[]
>>> ["first", "second", "third", "fourth", "fifth"][3::-1]
['fourth', 'third', 'second', 'first']
>>> ["first", "second", "third", "fourth", "fifth"][:0:-1]
['fifth', 'fourth', 'third', 'second']

[glyn]

I'm not aware of other open questions, so I think it's ok to change the implementation. As a cross-check, if you bump yaml-jsonpath, its behaviour should agree with what's needed here.

[cleidiano]

Got it, currently my implementation does not support negative step, there is a open issue to implement it, but I will freeze and wait a little bit.

[cburgmer]

Thanks for the thorough analysis.

I added another comparison Array slice with negative step and start greater than end.

I believe at the time of creating the query no implementation was returning anything meaningful for that, so I did not include it.

One more datapoint (and something users would compare to?):

$ python3
>>> ["first", "second", "third", "forth", "fifth"][0:3:-2]
[]
>>> ["first", "second", "third", "forth", "fifth"][3:0:-2]
['forth', 'second']

[remorhaz]

As for me, I've just used python (which seems to be used as a basis for ES4 slice proposal) spec/CLI to verify if my implementation works the same.

[remorhaz]

Old 2.0 docs seem to contain a bit more info.

[cburgmer]

I think at this stage I would try to follow the Python implementation, minus throwing an error if nothing was found, because that's up to the underlying implementation to decide.

If we agree, are there any open questions, or do we just need to make the change in the implementation?

[cleidiano]

Sorry for the late interaction, but Backwards seems to have advantages:

• All rules that it's applied when step is positive and already have a consensus could be applied.
• The only thing the user need to know is the direction that the operation would occur.

[glyn]

@cleidiano I initially adopted the Backwards approach in my implementation because of the advantages you describe. But I changed my mind becauset the Backwards behaviour is probably unintuitive to programmers familiar with for loops. I switched to Forwards A.

[cburgmer]

Closing this, at it seems we are happy with the way Proposal A is implementing this.