Python 3 slicing no longer uses __getslice__

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a slice in a production rule, eg:

def p_toplevel(p):
    """ toplevel : alpha beta gamma TOKEN delta """
    p[0] = p[1:4] + p[5:]

What is the expected output? What do you see instead?
Expected: p[0] is a list of the nonterminals alpha, beta, gamma, and delta.
Got:
  File "/usr/lib/python3.1/site-packages/ply/yacc.py", line 198, in __getitem__
    if n >= 0: return self.slice[n].value
TypeError: unorderable types: slice() >= int()

What version of the product are you using? On what operating system?

This is python 3.1, but this has been true since python 3.0: 
http://docs.python.org/py3k/whatsnew/3.0.html#operators-and-special-methods

Namely, instead of __getslice__ being called as it was in python 2.x, 
__getitem__ is called with a slice object, which is being compared with an int 
in YaccProduction's case. (Similarly, my testing shows that even in Python 2.7, 
a slice that includes a step, eg. a[1:4:2], sends a slice object to __getitem__ 
instead of to __getslice__.)

Simple patch included (Python 2 compatible) to fix this, but I note it allows 
the use of negative indices in slices in a way that doesn't match how negative 
indexing currently works.

Original issue reported on code.google.com by jokeserver on 28 Feb 2011 at 1:25

Attachments:

• getitem.patch

[GoogleCodeExporter]

I ran into this problem as well, but my fix was the following (also plays nice 
with negative indices):

   def __getitem__(self,n):
       if isinstance(n,slice):
           return [self[i] for i in range(*(n.indices(len(self.slice))))]
       else: # for integer indices, do what we used to
           if n >= 0: return self.slice[n].value
           else: return self.stack[n].value

Original comment by gasper.a...@gmail.com on 21 Dec 2011 at 5:18

[GoogleCodeExporter]

I'm not sure if using slices is really documented in PLY, but I'll make a fix 
in PLY-3.5.  --Dave

Original comment by d...@dabeaz.com on 21 Dec 2011 at 5:27

[GoogleCodeExporter]

Thanks! That would be great :)

Our project has been using slices in ply for years, and now that I tried 
porting it to python3 everything broke :)

Regards,

Gašper

Original comment by gasper.a...@gmail.com on 21 Dec 2011 at 5:29

[GoogleCodeExporter]

For what it's worth, I'm doing a bunch of compiler work with PLY right now in 
Python 3.   I don't use slices so I haven't encountered this, but I'm hoping to 
put out a new PLY release sometime in the near future (4-5 weeks).  If you find 
other bugs, please let me know.

Original comment by d...@dabeaz.com on 21 Dec 2011 at 5:34

[GoogleCodeExporter]

Just wanted to chime in that I experienced this issue today with Python 3...  
It has been over a year since it was reported and the attached patch fixes the 
issue.  Are there any plans to release 3.5 any time soon?  If not could we get 
a 3.4.1 release out that includes this patch?  Thanks!

Original comment by daniel.m...@liftoffsoftware.com on 19 Feb 2013 at 6:41

[GoogleCodeExporter]

I just upgraded my system and I'm running into this issue myself.  Any chance 
we can get a new version out with the patch applied?

Original comment by daniel.m...@liftoffsoftware.com on 25 Apr 2013 at 9:03

[GoogleCodeExporter]

Anything new concerning releasing Ply 3.5 fixing this bug?
Or do we have to avoid using slices in rules?

Original comment by tke...@gmail.com on 3 Dec 2013 at 10:46

[GoogleCodeExporter]

I'm pretty sure that this has already been fixed in github.  

Original comment by dbeaz...@gmail.com on 4 Dec 2013 at 10:16