Is this intended behavior? Creating zipfile.ZipFile with
relative path and changing current directory, relative path
is resolved from new directory not from the directory object
was created.

F:\>py3k
Python 3.2a4+ (py3k, Dec  3 2010, 22:11:05) [MSC v.1200 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
[67577 refs]
>>> zip = zipfile.ZipFile("non-ascii-cp932.zip", "r")
[68999 refs]
>>> import os
[69001 refs]
>>> os.mkdir("temp")
[69001 refs]
>>> os.chdir("temp")
[69001 refs]
>>> zip.extractall()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "e:\python-dev\py3k\lib\zipfile.py", line 992, in extractall
    self.extract(zipinfo, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 980, in extract
    return self._extract_member(member, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 1023, in _extract_member
    source = self.open(member, pwd=pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 901, in open
    zef_file = io.open(self.filename, 'rb')
IOError: [Errno 2] No such file or directory: 'non-ascii-cp932.zip'
[69128 refs]

I don't know, but I wouldn't call it a bug either.
In general it's not recommended to change the current directory except at the very beginning of your application.

More formally: it's unspecified. I'd like to propose this general principle: If you pass a relative path to some library that gets stored in the library, it's unspecified whether the cwd is consider at the point of passing the path or at the point of using it in some operation.

Applications that want to be cwd-agnostic must always use abspath.

The only exceptions are operations where there is some explicit open() operation that is documented to interpret the path name; for these, it is clear that the cwd is considered inside the open().

So, Martin, are you then arguing that this should in fact be considered a bug in ZipFile?  The documentation for the constructor says "Open a ZIP file, where file can be either a path to a file (a string) or a file-like object."  Reading that I would certainly expect it to accept a relative path, and for that path to be relative to the CWD at the time I called ZipFile, not at the time I called extractall.

> So, Martin, are you then arguing that this should in fact be
> considered a bug in ZipFile?  The documentation for the constructor
> says "Open a ZIP file, where file can be either a path to a file (a
> string) or a file-like object."  Reading that I would certainly
> expect it to accept a relative path, and for that path to be relative
> to the CWD at the time I called ZipFile, not at the time I called
> extractall.

You have a point here. So I now think that this should be changed.

The patch from issue14099 is intended to fix this issue.