On Tue, Mar 19, 2019 at 2:06 PM Stéphane Wirtel <steph...@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.version_info == 3.8) > > 3.9, we change PendingDeprecationWarning to DeprecationWarning > (check DeprecationWarning if sys.version_info == 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 mkname_unsafe() 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
