Message 164487 - Python tracker

➜

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	dlenski
Recipients	brian.curtin, dabrahams, davide.rizzo, dlenski, eric.araujo, eric.smith, jaraco, ncoghlan, pitrou, r.david.murray, sbt, tim.golden
Date	2012年07月01日.17:19:35
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<CAOw_LSErVeZzdruJKgksOQ71=VkFYW91D=0KyXeM6WoovL5xTg@mail.gmail.com>
In-reply-to	<1341072450.66.0.0658698533961.issue14243@psf.upfronthosting.co.za>

Content
Richard, I think the problem with this is that it spreads the non-portable or OS-dependent parts of the code over several places rather than concentrating them all in one place. After close_without_unlink(), what would happen when the context manager exits or when the object is garbage collected? Would it then get unlinked? My preference would be to specify the behavior of close/__exit__/GC operations at the time of the NamedTemporaryFile creation, so that the rest of the code can be left unchanged.

Content

Richard, I think the problem with this is that it spreads the non-portable
or OS-dependent parts of the code over several places rather than
concentrating them all in one place.
After close_without_unlink(), what would happen when the context manager
exits or when the object is garbage collected? Would it then get unlinked?
My preference would be to specify the behavior of close/__exit__/GC
operations at the time of the NamedTemporaryFile creation, so that the rest
of the code can be left unchanged.

History
Date	User	Action	Args
2012年07月01日 17:19:36	dlenski	set	recipients: + dlenski, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, eric.araujo, r.david.murray, brian.curtin, dabrahams, davide.rizzo, sbt
2012年07月01日 17:19:35	dlenski	link	issue14243 messages
2012年07月01日 17:19:35	dlenski	create

homepage