The docs (http://www.python.org/doc/2.5.1/lib/module-tempfile.html) specify that 
mkdtemp(), "returns the absolute pathname of the new directory".  It does that in 
the default case, but if you specify a relative path for 'dir', you get back a 
relative path.


$ python
Python 2.5.1 (r251:54863, Oct 17 2008, 14:39:09) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.mkdtemp(dir='.')
'./tmpHk1pBD'

similar results were obtained on:

Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin

Note that mkstemp() gets it right:

>>> tempfile.mkdtemp(dir='.')
'./tmpoPXdL7'
>>> tempfile.mkstemp(dir='.')
(3, '/Users/roy2/tmpwTGZ2y')
>>>

This is true on trunk and py3k as well.  2.5 is in security fix only
mode, so I've removed it from the versions list.

Since mkstemp does return in the absolute path in this case, I think
this is a code rather than a documentation bug.  However, changing it
would be backward incompatible, so it may not be possible to fix it in
2.6 and 3.1.

It's a border case for backporting. The docs do say it should be returning 
an absolute path, so that is a bug. And chances are anyone who has 
discovered this and is working around it simply called os.path.abspath() 
on the value instead of some manual calculation (if at all; bigger chance 
no one simply noticed).

My vote is to backport. Otherwise the docs should be updated for 2.6/3.1 
to mention the bug.

I think we should be conservative. People may be relying on it *not*
returning an absolute path; besides, the bug itself wasn't a problem in
practice, so backporting the fix doesn't bring any added value.

I have created a patch for this for Python 3.1 and included an update to the unit tests.  The tests were never checking for a relative path and if they did would pas it even when it would have failed due to liberal use of os.path.abspath()

The test fix is probably not as clean as it could be by I did not want to severely alter its state.  The change to tempfile.mkdtemp() was clear and followed the current method tempfile.mkstemp() uses.

As a side note, this was done mostly as an exercise for myself and as a learning experience.  Any feedback would be appreciated regardless of any decision on the status of this bug.

First of all, thanks for working on this.  Now for some feedback :)

It is most helpful if you provide patches against trunk (which is 2.7 alpha right now).  We then forward port them to py3k.  (This will change after the release of 2.7, when py3k will become trunk.)

Isn't the assert you added to nameCheck redundant?  It seems to me it would be better just to remove the abspath call on ndir from the existing assert.

I haven't applied and tested the patch, but the other changes to the tests look odd to me.  Why are you obtaining the abspath of the current directory?  And why do those tests need to be changed at all?

Your additional test case looks like it might be some exploration code you forgot to delete before generating the patch, maybe those other changes are as well?

I agree, I do not feel like the precise changes to the tests feel completely ideal.  I feel that this problem stems from the fact that the nameCheck function as originally written doesn't seem to completely serve its originally intended purpose.

The original issue that caused the modifications of the tests were as follows:

* After adding "test_abs_path()" namecheck would pass the test when it should actually fail due to the original assert performing os.path.abspath() on both paths.  The obviously solution to this seemed to be to take the abspath of the user supplied path (the variable dir in this function) relative or otherwise and compare to ndir which is derived from the passed in "name" variable, populated by the mkdtemp call.

* The second issue is a somewhat complex case of those asserts passing the atypical odd calls of nameCheck from the "test__RandomNameSequence" suite.  Without absolute pathing of both parameters in the new first assert this test began to fail.  This is because the original call was self.namecheck(<file name>, '', '', '').  These empty parameters when called with os.path.abspath() would return valid paths and these asserts would succeed.  As a result, the abspath(join()) call built a proper path into the "name" parameter allowing the tests to pass in this case.

* For the sake of cleanliness I decided it made more sense to split the two apart.  Make one assert that specifically verifies the path the file/folder is being placed in is both absolute and matching and one that will pass the file name.  Perhaps the old first assert (or second assert in the patch) can actually be removed but I think it may be getting properly tested against in one of the other test classes.

I am quite confident there is a much better way to accomplish this but I did not wish to change _too_ much of the test on my first stab at this.

I appreciate your feedback very much.  I will work on setting up the 2.7 environment for working on issues that span the 2x/3x gap.

One other thing that crossed my mind while I was thinking over this today.  Instead of just relative pathing to '.' I should probably change my path to gettempdir() and then relative path to it since the location of the python executable may not be writable.

Any thoughts on how to go about testing this in a way that is most likely to succeed in all cases and respect OS permissions?

I made a new patch off of the 2.7 trunk version.  I think I have handled some of the issues more cleanly.

Please see Py(27)7325.diff

I addressed the issue of using a relative path in the tempdir to achieve the 'guaranteed' ability to write rather than assuming the location of the python executable was writable.

Tried this on windows against 2.7 don't see why it can't go forward.

Thomas, I think the weirdness you were sensing when trying to adapt the nameCheck calls in test__RandomNameSequence after adding the abspath check is that those test cases really don't need nameCheck.

For example, test_get_six_char_str should be testing that _RandomNameSequence returns something that is both a string and 6 characters, not properties of some path manufactured around it.

I've attached a patch based on Thomas's that factors out the string check in nameCheck and has the tests in test__RandomNameSequence just use the string check.

The patch is against release27-maint.

Hi people,
I insert a simple code in tempfile.py, that verify if the return starts with ./, and concatenate using the abspath function.
I changed the variable name file to temp_dir_abspath, because file is a built-in function and it's not recommended, overwrite it with local variables.
And at least i add one test, that verify if temp_directory returns an absolut path.

thanks.

Looks good to me, with one exception:

 if temp_dir_abspath.startswith('./'):

Wouldn’t this be better:

 if not _os.path.isabs(temp_dir_abspath)

(P.S. file is not a builtin anymore in 3.x, it’s used for example as an argument to the print function.)

You is right, i put this command on test and not the test.
thankss

os.path.abspath actually checks for isabs first, so I think you can leave the test out and always call abspath.

I think we should resolve this one line change.

Jessica’s patch looks just fine, so I tend to apply it.  However, I’d like to document the current behavior in 2.7, 3.2, 3.3 and 3.4.

Am I missing anything?

bump? see also #20267

It's still the same in 3.11. I don't know whether this is something to fix in the code or in the docs.

>> import tempfile
>>> tempfile.mkdtemp(dir='.')
'./tmplvkt14za'
>>> tempfile.mkstemp(dir='.')
(3, '/Users/iritkatriel/src/cpython/tmp86ljh34k')