[Python-Dev] Improved tmpfile module

[Greg Ward]

On 27 June 2002, Zack Weinberg said:
> Well, I wrote the analogous code in the GNU C library (using basically
> the same algorithm).  I'm confident it is safe on a Unix-based system.
> On Windows and others, I am relying on os.open(..., os.O_EXCL) to do
> what it claims to do; assuming it does, the code should be safe there too.

Sounds like good credentials to me.  Welcome to Python-land!  Note that
you'll probably get more positive feedback if you provide a patch to
tmpfile.py rather than a complete rewrite.  And patches will get lost on
python-dev -- you should submit it to SourceForge, and stay on the case
until the patch is accepted or rejected (or maybe deferred).

[me]
> +1 except for the name.  What does the "s" stand for?  Unfortunately, I
> can't think of a more descriptive name offhand.

[Zack]
> Fredrik Lundh's suggestion that it is for "safer" seems plausible, but
> I do not actually know.  I chose the names mkstemp and mkdtemp to
> match the functions of the same name in most modern Unix C libraries.
> Since they don't take the same "template" parameter that those
> functions do, that was probably a bad idea.

Hmmmm... I'm torn here.  When emulating (or wrapping) functionality from
the standard C library or Unix kernel, I think it's generally good to
preserve familiar, long-used names: os.chmod() is better than
os.changemode() (or change_mode(), if I wrote the code).  But mkstemp()
and mkdtemp() are *not* familiar, long-used names.  (At least not to me
-- I program in C very rarely!)  But they will probably become more
familiar over time.

Also, API changes that are just due to fundamental differences between C
and Python (immutable strings, multiple return values) are not really
enough reason to change a name.

It looks like your Python mkstemp() has one big advantage over the glibc
mkstemp() -- you can supply a suffix.  IMHO, the inability to supply a
prefix is a small disadvantage.  But those add up to a noticeably
different API.  I think I'm slightly in favour of a different name for
the Python version.  If you make it act like this:

    mkstemp(template : string = (sensible default),
            suffix : string = "")
    -> (filename : string, fd : int)

(err, I hope my personal type language is comprehensible), then call it
mkstemp() after all.  

> [Note to Fredrik: at the C level, mkstemp is not deprecated in favor
> of tmpfile, as they do very different things - tmpfile(3) is analogous
> to tmpfile.TemporaryFile(), you don't get the file name back.]

But the man page for mkstemp() in glibc 2.2.5 (Debian unstable) says:

       Don't  use  this  function, use tmpfile(3) instead.  It is
       better defined and more portable.

BTW, that man page has two "NOTES" sections.

> I was trying to get all the user-accessible interfaces to be at the
> top of the file.  Also, I do not understand the bits in the existing
> file that delete names out of the module namespace after we're done
> with them, so I wound up taking all of that out to get it to work.  I
> think the existing file's organization was largely determined by those
> 'del' statements.
> 
> I'm happy to organize the file any way y'all like -- I'm kind of new
> to Python and I don't know the conventions yet.

If I was starting from scratch, I would *probably* do something like
this:

  if os.name == "posix":
      class TemporaryFile:
         [... define Unix version of TemporaryFile ...]

  elif os.name == "nt":
      class NamedTemporaryFile:
         [...]

      class TemporaryFile:
         [... on top of NamedTemporaryFile ...]

  elif os.name == "macos":
      # beats me

But I don't know the full history of this module.

IMHO you would have a much better chance of success if you prepared a
couple of patches -- eg. one to add mkstemp() and mkdtemp() (possibly
with different names), another to do whatever it is to TemporaryFile
that you want to do.  Possibly a third for general code cleanup, if you
feel some is needed.  (Or do the code cleanup patch first, if that's
what's needed.)

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
I hope something GOOD came in the mail today so I have a REASON to live!!