Error when deleting and reimporting subpackages
Hi, I recently ran into this behavior: >>> import sys >>> import apkg.subpkg >>> del sys.modules['apkg'] >>> import apkg.subpkg as subpkg Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'subpkg' where 'apkg' and 'subpkg' comprise empty __init__.py files to simplify the example. It appears then, that importing a subpackage, then deleting the containing package from sys.modules, orphans the subpackage in an unfixable state. I ran into this because the nose testing framework does exactly this kind of thing when loading test modules, causing some very confusing errors and failures. Is this behavior expected? Best, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: Error when deleting and reimporting subpackages
On Monday, August 22, 2011 12:06:44 PM UTC-7, Stephen Hansen wrote: > On 8/22/11 11:51 AM, Matthew Brett wrote: > > Hi, > > > > I recently ran into this behavior: > > > >>>> import sys > >>>> import apkg.subpkg > >>>> del sys.modules['apkg'] > >>>> import apkg.subpkg as subpkg > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'module' object has no attribute 'subpkg' > > > > where 'apkg' and 'subpkg' comprise empty __init__.py files to simplify the > > example. > > > > It appears then, that importing a subpackage, then deleting the containing > > package from sys.modules, orphans the subpackage in an unfixable state. > > > > I ran into this because the nose testing framework does exactly this kind > > of thing when loading test modules, causing some very confusing errors and > > failures. > > > > Is this behavior expected? > > Yes. Doing an import of "apkg.subpkg" results in more then just "test1" > being cached in sys.modules, and you're removing half of that so leaving > Python in a weird state. > > You also want to del sys.modules["apkg.subpkg"], then you'll be able to > re-import apkg.subpkg. I.e: > > Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) > [GCC 4.2.1 (Apple Inc. build 5664)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> import test1.test2 > >>> del sys.modules['test1'] > >>> del sys.modules['test1.test2'] > >>> import test1.test2 as test2 > >>> Yes, sorry, I should have mentioned that I explored these kind of variations. I think I see that there isn't an obvious way for del sys.modules['apkg'] to know to delete or modify 'apkg.subpkg', because sys.modules is just a dict. However, I could imagine the import machinery being able to recognize that 'apkg.subpkg' is broken, and re-import it without error. Is that reasonable? Best, Matthew -- http://mail.python.org/mailman/listinfo/python-list
zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi,
I sorry if this is a bad place to ask, but I wanted to find out if the
behavior I'm seeing is a bug.
I maintain scipy's matlab file readers, and I came across a zlib
compressed string that causes a zlib error on decompression, but only
with zlib.decompress, not zlib.decompressobj.
I saved the original compressed string as a binary file at
http://dl.dropbox.com/u/794947/mat.bin
Now if I do:
import zlib
data = open('mat.bin', 'rb').read()
out = zlib.decompress(data)
I get an error : Error -5 while decompressing data)
If instead I do this:
out = zlib.decompressobj().decompress(data)
I get a usable uncompressed string. I was expecting these two calls
to do the same thing. Is that expectation right? If not, is there
somewhere I could find out why?
Thanks a lot,
Matthew
--
http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, Thanks for the reply. > > If instead I do this: > > > out = zlib.decompressobj().decompress(data) > > How about: > > d = zlib.decompressobj() > out = d.decompress(data) + d.flush() Do you mean, that you would then expect the decompressobj method to fail as well? But, no, d.flush() returns the empty string after decompressing ``data``. Thanks again, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, > > Do you mean, that you would then expect the decompressobj method to > > fail as well? > > Yes. > > > But, no, d.flush() returns the empty string after decompressing > > ``data``. > > Hmm, then it's a bug. Can you report it tohttp://bugs.python.org? I will - thanks for your advice, Matthew -- http://mail.python.org/mailman/listinfo/python-list
