[Python-Dev] Remove tempfile.mktemp() (original) (raw)

Giampaolo Rodola' g.rodola at gmail.com
Tue Mar 19 12:23:00 EDT 2019

On Tue, Mar 19, 2019 at 2:06 PM Stéphane Wirtel <stephane at wirtel.be> wrote:

Hi, Context: raise a warning or remove tempfile.mktemp() BPO: https://bugs.python.org/issue36309 Since 2.3, this function is deprecated in the documentation, just in the documentation. In the code, there is a commented RuntimeWarning. Commented by Guido in 2002, because the warning was too annoying (and I understand ;-)). So, in this BPO, we start to discuss about the future of this function and Serhiy proposed to discuss on the Python-dev mailing list. Question: Should we drop it or add a (Pending)DeprecationWarning? Suggestion and timeline: 3.8, we raise a PendingDeprecationWarning * update the code * update the documentation * update the tests (check a PendingDeprecationWarning if sys.versioninfo == 3.8) 3.9, we change PendingDeprecationWarning to DeprecationWarning (check DeprecationWarning if sys.versioninfo == 3.9) 3.9+, we drop tempfile.mktemp() What do you suggest?

I concur with others who think this should not be removed. It's used in different stdlib and third party modules' test suites. I see tempfile.mktemp() very similar to test.support.find_unused_port() and os.path.exists/isfile/isdir functions: they are all subject to race conditions but still they are widely used and have reason to exist (practicality beats purity). I suggest turning the doc deprecation into a note:: or warning::, so that extra visibility is maintained. Because the use case is legitimate and many fs-related APIs such as this one are inevitably racy, I lean more towards a note:: rather than a warning:: though, and we could probably do the same for os.path.is* functions.

@Sebastian

If there are valid use cases for mktemp(), I recommend renaming it to mknameunsafe() or something equally obvious.

I'm -1 about adding an alias (there should be one and preferably only one way to do it). Also mkstemp() and mkdtemp() are somewhat poorly named IMO, but I wouldn't add an alias for them either.

-- Giampaolo - http://grodola.blogspot.com

More information about the Python-Dev mailing list