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!!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4