[Tutor] MemoryError

Kent Johnson kent37 at tds.net
Thu Dec 9 12:33:05 CET 2004


Liam,

I'm sorry to hear you so discouraged.

It sourds like your program has gotten too big for you to clearly understand what it is doing. An 
earlier poster suggested that you break your program up into functions. This is a very good idea, 
especially if you do it from the start.

A very powerful technique for developing a complex program is to start with small pieces and build 
up from them. The pieces can be coded *and tested* independently. Because they are known to work, 
you can confidently build larger pieces by hooking together the small ones.

In your case, a very simple place to start would be a function to get rid of the '=\n' and '=3D' 
strings:

def cleanup(codeSt):
	codeSt=codeSt.replace("=\n",'')
	codeSt=codeSt.replace('=3D','=')
	return codeSt

Using the unittest module you could write a test like this:

import unittest

class CodeFixTest(unittest.TestCase):
     def test_cleanup(self):
         self.assertEquals('<applet code="fphover.class">', cleanup('<app=\nlet 
code=3D"fphover.class">'))


if __name__ == '__main__':
     unittest.main()

That's pretty simple. Now move on to a function that, given an applet tag, figures out the 
corresponding link tag. Write tests for that function using examples from your actual data.

You could have another function that finds the applet tags. Finally a function that puts it all 
together. Still you can have unit tests that make sure it is working correctly.

When you are done you have a working, well-tested program and a suite of unit tests for it. Keep the 
tests - they will be handy if you ever want to make a change.

HTH
Kent

Liam Clarke wrote:
> Well, I figured out the memory error relatively easily once I poked
> some stuff, I was using codeSt.find instead of codeSt.index, so it was
> returning no matches as -1, index raises an error for me, and I wasn't
> catering for that -1. The MemoryError occurred when Python wanted to
> slice from 160,000 to -1 or 0.
> 
> Was quite funny watching 1 Gb of paging file disappear in seconds.
> 
> But, I give up. Now, I've got several more bugs pop up. I've got an
> index of integers that has the occasional index stored as a string. I
> have indexes that start pointing at the right place, but when it comes
> time to slice, the right place has moved. Unsure why, I'm specifically
> moving from highest to lowest to avoid messing with the index values.
> Even if nothing changes, my stored indexes go off course. This is
> yuck.
> 
> So, I'm going to throw caution to the wind, and try an re approach. It
> can't be any more unwieldy and ugly than what I've got going at the
> moment.
> 
> Thanks for all the help, I'm off to get myself another problem.
> 
> Regards,
> 
> Liam Clarke
> 
> On Wed, 08 Dec 2004 15:25:30 -0800, Jeff Shannon <jeff at ccvcorp.com> wrote:
> 
>>Liam Clarke wrote:
>>
>>
>>>>I'm not sure why you're getting the MemoryError, but it'd be easier to
>>>>figure out if you posted the entire text of the traceback.
>>>
>>>Traceback: <usual bit about in module..>
>>>
>>>Line 39: seg=codeSt[element:endInd+len(endStr]
>>>MemoryError
>>>
>>>Hehe. Helpful, no?
>>
>>Actually, it was the "usual bit about in module" that might *be*
>>helpful. ;)  Often, something can be determined by the sequence of
>>function calls listed there.  Though I suppose, now that I think of
>>it, that since your code is all module-level, there wouldn't be any
>>function stack in this case...   Still, in general, when asking for
>>help with something that throws an exception, it's always best to copy
>>& paste the entire text of the exception.
>>
>>One thing that I've noticed, which I thought was just a typo in your
>>original email but which is duplicated again here (it's not present on
>>the web page you linked to) -- you have a mismatched parenthesis in
>>your len() call.  It's "[ ... len(endstr]" -- there's no ')' to close
>>the function call.  Given that this typo isn't on the web page, I'm
>>not sure whether it's actually there in the code you're running or
>>not.  I'd have *thought*, however, that if it *is* present, you'd get
>>a syntax error rather than a memory error, so it's probably not there
>>but you should check it anyhow.  :)
>>
>>
>>
>>Jeff Shannon
>>Technician/Programmer
>>Credit International
>>
>>_______________________________________________
>>Tutor maillist  -  Tutor at python.org
>>http://mail.python.org/mailman/listinfo/tutor
>>
> 
> 
> 


More information about the Tutor mailing list