The linker on Linux reports some warnings for 
posixmodule.c:

libpython2.2.a(posixmodule.o): In function `posix_tmpnam':
/home/lemburg/projects/Python/Dev-Python/./Modules/posixmodule.c:4486:
the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.2.a(posixmodule.o): In function `posix_tempnam':
/home/lemburg/projects/Python/Dev-Python/./Modules/posixmodule.c:4436:
the use of `tempnam' is dangerous, better use `mkstemp'
Perhaps we ought to follow the advice ?!

Logged In: YES 
user_id=21627

No. The usage of tmpnam is not dangerous; we are just
exposing it to the Python application. It may be reasonable
to produce a warning if tmpnam is called.

We cannot replace tempnam with mkstemp for the same reason
Posix couldn't: one produces a string, the other one a file
handle. 

What we could do is to expose mkstemp(3) where available. I
don't see the value of that, though: it could be done only
on systems where mkstemp is available, and we already expose
tmpfile(3). In fact, the Linux man page for mkstemp(3) says

# Don't use this function, use tmpfile(3) instead. It's 
# bet­ter defined and more portable.
If you still think there is a need for action, please
propose a patch.

Logged In: YES 
user_id=38388

Hmm, the man page on SuSE Linux does not say anything about using tmpfile() instead of mkstemp().

BTW, the warnings are already in place.

I wonder whether it wouldn't be better to remove the Python APIs for these functions altogether and 
instead provide interfaces for the mkstemp() and/or tempfile().

Logged In: YES 
user_id=21627

We already expose os.tmpfile, I don't think we need mkstemp.

I don't think we should remove tmpnam; applications that use
it will get the warning (for the first time in 2.2); we
should leave it to the applications to migrate away from it.

I found the recommendation not to use mkstemp on a Debian
'testing' system; dunno whether it was added by the Debian
maintainers, or whether it is part of more recent manpage
package.

Logged In: YES 
user_id=38388

Ok. How about this: we produce warnings for the two APIs in question in 2.2 and drop their support in 2.3 ?!

I hate seeing the linker warn me about Python using dangerous system APIs -- this simply doesn't look right.

Logged In: YES 
user_id=21627

Before they can be dropped, they must be deprecated. In this
case, I see no real reason to deprecate them: They produce a
warning indicating a potential problem. For some
applications, there may not be a problem at all, e.g. if
they write the temporary files to a directory where nobody
else has write access, or if they open the temporary file
with O_EXCL.

There *are* ways to use tempnam safely. I don't think we
should change Python just because of a stupid linker warning
(which isn't stupid in general, since it made you aware of
the problem - but it is unfortunate that it cannot be turned
off).