- May 13, 2017
-
-
Gregory Szorc authored
Support for using unittest.TestCase.assertRaises as a context manager was added in Python 2.7. This form is more readable, especially for complex tests. While I was here, I also restored the use of assertRaisesRegexp, which was removed in c6921568cd20 for Python 2.6 compatibility.
-
- Oct 17, 2016
-
-
Mads Kiilerich authored
-
- Jun 23, 2016
-
-
Martijn Pieters authored
Close the file (moving it in place) on clean context exit, discard when there has been an exception.
-
Martijn Pieters authored
-
Martijn Pieters authored
These tests are independent and numbering only makes it harder to add more and logically group them.
-
Martijn Pieters authored
Rather than pre-emptively delete a file, execute the test in a dedicated temporary directory that is removed after each test.
-
- May 18, 2016
-
-
Katsunori FUJIWARA authored
Ambiguity check is executed at close(), only if: - atomictempfile is created with checkambig=True, and - target file exists before renaming This restriction avoids performance decrement by needless examination of file stat (for example, filelog doesn't need exact cache validation, even though it uses atomictempfile to write changes out). See description of filestat class for detail about why the logic in this patch works as expected. This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
-
- May 15, 2016
-
-
Pulkit Goyal authored
-
- Apr 20, 2016
-
-
timeless authored
-
- Feb 09, 2013
-
-
Idan Kamara authored
-
- Aug 26, 2011
-
-
Greg Ward authored
The usual contract is that close() makes your writes permanent, so atomictempfile's use of close() to *discard* writes (and rename() to keep them) is rather unexpected. Thus, change it so close() makes things permanent and add a new discard() method to throw them away. discard() is only used internally, in __del__(), to ensure that writes are discarded when an atomictempfile object goes out of scope. I audited mercurial.*, hgext.*, and ~80 third-party extensions, and found no one using the existing semantics of close() to discard writes, so this should be safe.
-
- Apr 24, 2011
-
-
Greg Ward authored
The problem is that a programmer using atomictempfile directly can make an innocent everyday mistake -- not enough args to the constructor -- which escalates badly. You would expect a simple TypeError crash in that case, but you actually get an infinite recursion that is surprisingly difficult to kill: it happens between __del__() and __getattr__(), and Python does not handle infinite recursion from __del__() well. The fix is to not implement __getattr__(), but instead assign instance attributes for the methods we wish to delegate to the builtin file type: write() and fileno(). I've audited mercurial.* and hgext.* and found no users of atomictempfile using methods other than write() and rename(). I audited third-party extensions and found one (snap) passing an atomictempfile to util.fstat(), so I also threw in fileno(). The last time I submitted a similar patch, Matt proposed that we make atomictempfile a subclass of file instead of wrapping it. Rejected on grounds of unnecessary complexity: for one thing, it would make the Windows implementation of posixfile quite a bit more complex. It would have to become a subclass of file rather than a simple function -- but since it's written in C, this is non-obvious and non-trivial. Furthermore, there's nothing wrong with wrapping objects and delegating methods: it's a well-established pattern that works just fine in many cases. Subclassing is not the answer to all of life's problems.
-