Paul McGuire wrote:
> Hrmm, I had a sneaking hunch this might be the issue. But then I
> don't know how this code *ever* worked in Python 3, as it is chock
> full of indexed references into the string being parsed. And yet,
> I've had other folks test and confirm that pyparsing_py3 *does* work
>
On May 25, 8:58 pm, Benjamin Peterson wrote:
> Paul McGuire austin.rr.com> writes:
>
> > In this section of code, instring is a string, loc is an int, and wt
> > is a string. Any clues why instring[loc] would be evaluating as int?
> > (I am unfortunately dependent on the kindness of strangers wh
Paul McGuire wrote:
[...]
> while loc < instrlen and instring[loc] in wt:
> TypeError: 'in ' requires string as left operand, not int
>
> In this section of code, instring is a string, loc is an int,
In Python 3, lots of things that used to return str now return bytes,
and the elements of a bytes
Paul McGuire austin.rr.com> writes:
> In this section of code, instring is a string, loc is an int, and wt
> is a string. Any clues why instring[loc] would be evaluating as int?
> (I am unfortunately dependent on the kindness of strangers when it
> comes to testing my Python 3 code, as I don't ha
I was teetering on the brink of releasing Pyparsing 1.5.3 (with some
nice new examples and goodies), when I saw that I had recently
introduced a bug in the Python 3 compatible version. Here is the
stacktrace as reported on SF:
Traceback (most recent call last):
File "testcase.py", line 11, in
re
