So if you don't have the collect in there, but have the dels and run under the normal Python interpreter, the memory usage still increases? That would suggest we have a reference cycle somewhere to take care of. If you're able to share your output files (dropbox or something) I can play with this a bit.
It seems unlikely that memory is truly leaking. If you're running under ipython, and particularly under the debugger, it tends to hold on to object references which keep them from going out of scope and thus being deleted. There's also the possibility of a reference cycle being created. To check this, modify your simple test script and before the return in readpb put: del f del x and then at the bottom of your main loop: print(i) time.sleep(60) (add "import time" to the top, of course.) Then run...
toolbox doesn't work
The 302 suggests to me you may behind a proxy that isn't completely set up...but if it's working now, no sense in digging further! I'm closing this bug for now and can reopen later if necessary.
Did you also update the urls in the rc file, assuming that was an issue? To double-check: import spacepy print(spacepy.config['qindenton_url']) That should give http://virbo.org/ftp/QinDenton/hour/merged/latest/WGhour-latest.d.zip If that's correct, I'm starting to suspect something in your environment. Has toolbox.update ever worked for you? Can you check if you're behind a proxy server (try, e.g. http://www.whatismyproxy.com/ ). Then see if that information is passed through to Python: import os...
I presume you mean toolbox,update() doesn't work...if you are having other issues with toolbox, please open another issue for them. The locations need to be changed in your spacepy.rc file; to find the location of this file, start Python and: import spacepy print(spacepy.rcfile) The documentation is also available at readthedocs Based on your traceback, you will need to revert your changes...the lines you changed are the name of the variable holding the URL, not the URL.
I used exactly the code in my first comment, plus your changes elsewhere in the file, and it worked fine on 3.5. I don't have a 3.6 install that I've proven to work with the whole SpacePy stack but I really doubt that'd be an issue. I'd probably make it: if dtype is str and str is not bytes and type(A) is bytes: A = A.decode() just to make sure what's coming in really needs decoding to str. (At that point the "dtype is str" would probably be redundant.)
You get exceptions indicating the bytes were not being decoded to str when you use the test for Python 3 in the form "str is not bytes" but not in the test on sys.version, regardless of the sense of the dtype comparison? Is this failing in a unit test so I can check? (I see that str here will always be str since it's being used more as a flag than the dtype of the actual data.)