Extended slice notation missing about rapydscript HOT 4 CLOSED

The problem is JavaScript doesn't have the concept of efficiently slicing an array arbitrarily like Python does. This means that extended slicing would effectively downgrade the slice to a regular loop behind the scenes, if you're fine with that I can implement it.

I also want to once again reiterate that RapydScript is not Python, and the fact that Python 2 and 3 do something, doesn't mean RapydScript must do it. The idea is to enable developer to be more productive in JavaScript world, thinking along the same design patterns as one would in Python is the goal, rather than mimicking Python syntax exactly.

from rapydscript.

Will have compiler handle this notation when I have some time to look into the parser, in the meantime here is a stopgap solution:

def eslice(arr, step, start=0, end=arr.length):
    sliced = arr.slice(start, end)
    if type(arr) == 'string' or isinstance(arr, String):
        isString = True
        sliced = sliced.split('')
    if step < 0:
        step = -step
        sliced.reverse()
    sliced = sliced.filter(def(e, i): return i % step == 0;)
    return isString ? sliced.join('') : sliced

from rapydscript.

Excellent explanation on RapydScript not being a Python clone, agreed on all points there. I don't expect it to faithfully emulate all aspects of Python, but more in a CoffeeScript-like role - to smooth over Javascript's rough edges (with Python-like features).

The stopgap however, is not ideal. The reverse operation, with a negative step works, if we're considering the whole list (or Array). What doesn't work, is passing indices with negative step slicing. One example, very much like the initial ones:

Python2:

>>> range(1, 10)[7:0:-1]
[8, 7, 6, 5, 4, 3, 2] 
# note that the element at the end index (0) was skipped, as is for regular slicing

Rapydscript, browser console when using eslice as above:

// argument order not intuitive, should be same as slicing?
eslice([1,2,3,4,5,6,7,8,9], -1, 7, 0)
Array [  ]

Which is of course because slice in line 2 doesn't account for the reversed indices.

Now, this might come out as nitpicking, digging out some obscure corners of Python to "prove" Rapydscript is bad, because it's not 200% compliant. That's not my intent, feel free to do anything, it's your project. But the closer to Python semantics it is, the less surprises for a new (or an experienced, trying to appy his/her skills at Rapydscript) developer there are.

from rapydscript.

Here is a version that works better, although it is uglier because I couldn't make use of default argument values due to possibility of inverted order:

def eslice(arr, step, start, end):
    arr = arr[:]
    if type(arr) == 'string' or isinstance(arr, String):
        isString = True
        arr = arr.split('')

    if step < 0:
        step = -step
        arr.reverse()
        if type(start) != "undefined":
            tmp = start + 1
        if type(end) != "undefined":
            start = end + 1
        end = tmp
    if type(start) == "undefined": start = 0
    if type(end) == "undefined": end = arr.length

    arr = arr.slice(start, end).filter(def(e, i): return i % step == 0;)
    return isString ? arr.join('') : arr

All of the following have been tested to work:

range(1, 10)[7:0:-1]
range(10)[::2]
range(10)[::-1]
'abcd'[::2]
'abcd'[::-1]

I will later update the compiler to make [#:#:#] into syntax sugar for the above function call, but I want to rip out baselib generation logic into a separate module first for better readability.

from rapydscript.