rdrink wrote: > Ok, maybe now I can make some more sense of this, with an example of > real code (sorry if it's a bit dense): > This is the basic function... > > def equate(parts,new_eq): > > oL = int(parts[0]) > iL = int(parts[1]) > iR = int(parts[2]) > oR = int(parts[3]) > oLoL = int(str(oL)+str(oL)) > oLiL = int(str(oL)+str(iL)) > oLiR = int(str(oL)+str(iR)) > oLoR = int(str(oL)+str(oR)) > iLoL = int(str(iL)+str(oL)) > iLiL = int(str(iL)+str(iL)) > iLiR = int(str(iL)+str(iR)) > iLoR = int(str(iL)+str(oR)) > iRoL = int(str(iR)+str(oL)) > iRiL = int(str(iR)+str(iL)) > iRiR = int(str(iR)+str(iR)) > iRoR = int(str(iR)+str(oR)) > oRoL = int(str(oR)+str(oL)) > oRiL = int(str(oR)+str(iL)) > oRiR = int(str(oR)+str(iR)) > oRoR = int(str(oR)+str(oR)) > > new_seed = eval(new_eq) > return new_seed > > ... into which is passed two items: > - 'parts' , which is a list e.g ['12','34','56','78'] (of strings)
That's a lot of calls to str() to change the parts of parts *back* into strings after changing them into ints. Why don't you just say something like: soL, siL, siR, soR = parts oL, iL, iR, oR = map(int, parts) oLoL = int(soL + soL) oLiL = int(soL + siL) . . . etc... ? If you're calling this function as many times as you indicate below (just under a quarter of a million(!) if I understand you correctly, 480*500 = 240,000) , it might even result in a human-noticeable speed up. ;-) > - and 'new_eq',which is also a string read from a text file, e.g. > "pow(oLiL,2)" > > And so...for the first 9 entries (of 480) in the text file where... > pow(oLiL,2) > pow(oLiL,2) - oL > pow(oLiL,2) - iL > pow(oLiL,2) - iR > pow(oLiL,2) - oR > pow(oLiL,2) + oL > pow(oLiL,2) + iL > pow(oLiL,2) + iR > pow(oLiL,2) + oR > pow(oLiL,2) > pow(oL - iL,2) > ... eval() works fine. > But on the 10th... > pow(oL - iL,2) - oL > ... it bombs with the error: > pow(oL - iL,2) - oL > Traceback (most recent call last): > File "the_farmer2.py", line 264, in ? > seed = equate(parts,equation) > File "the_farmer2.py", line 112, in equate > iL = int(parts[1]) > ValueError: invalid literal for int(): - Ok, so there you go. At this point in the program parts[1] is '-', which isn't an int literal, so the script raises an exception. One very good thing to do here, as others have already mentioned, would be to "print parts" at the beginning of your equate() function. That way you could see exactly which data are causing the problem. > > And what is interseting/odd is: > - For the third, '- iL' evaluates fine... > - as well as the 9th, [where it is nested, oL - iL, inside pow()] ... > - but in the 10th, where a subtraction is called twice, it doesn't. None of this has anything to do with the error you posted. You're not even getting as far as calling eval() or pow(). If you read the traceback carefully, starting at the last line in it and working backwards, you'll see that you're calling int() with an invalid literal '-', and that this occurs on line 112, in file "the_farmer2.py", in the equate() function. The traceback even presents you with a copy of the line in question: "iL = int(parts[1])" so you know where the '-' is coming from. It's coming from parts[1]. > Which leads me to believe that the problem is either inside eval() it's > self, or in the way these variables are being cast... but I can't tell > which. The traceback tells you, unambiguously, that it's the latter, the variable cast. That's *why* tracebacks exist, and why python prints them by default: to tell you as much as it can about exactly what went wrong. > > (BTW, as a footnote: For each of the above 'equations' the function > equate() was called 500 times... in some cases with the list 'parts' > equaling things like ['0',2','3','0'], so I have no reason to believe > that the problem is with the way the list is being passed in... but I > could be wrong) > > Can anyone see something I can't? Learn to read tracebacks. They're your friends. Peace, ~Simon -- http://mail.python.org/mailman/listinfo/python-list
