[CalendarServer-changes] [2068] CalendarServer/trunk/HACKING

[source_changes at macosforge.org]

Revision: 2068
          http://trac.macosforge.org/projects/calendarserver/changeset/2068
Author:   wsanchez at apple.com
Date:     2007-12-12 16:54:08 -0800 (Wed, 12 Dec 2007)

Log Message:
-----------
Add not about proactively closing files

Modified Paths:
--------------
    CalendarServer/trunk/HACKING

Modified: CalendarServer/trunk/HACKING
===================================================================
--- CalendarServer/trunk/HACKING	2007-12-12 23:42:24 UTC (rev 2067)
+++ CalendarServer/trunk/HACKING	2007-12-13 00:54:08 UTC (rev 2068)
@@ -285,12 +285,6 @@
        "And here is yet another string.",
      )
 
- * If a callable is going to return a Deferred some of the time, it
-   should probably return a deferred all of the time.  Return
-   succeed(value) instead of value if necessary.  This avoids forcing
-   the caller to check as to whether the value is a deferred or not.
-   (eg. by using maybeDeferred())
-
  * Doctrings are important.  All public symbols (anything declared in
    __all__) must have a correct docstring.  The script
    docs/Developer/gendocs will generate the API documentation using
@@ -312,6 +306,36 @@
        ...
        """
 
+Best Practices
+==============
+
+ * If a callable is going to return a Deferred some of the time, it
+   should probably return a deferred all of the time.  Return
+   succeed(value) instead of value if necessary.  This avoids forcing
+   the caller to check as to whether the value is a deferred or not.
+   (eg. by using maybeDeferred())
+
+ * Be proactive about closing files and file-like objects.
+
+   For a lot of Python software, letting Python close the stream for
+   you works fine, but in a long-lived server that's processing many
+   data streams at a time, it is important to close them as soon as
+   possible.
+
+   On some platforms (eg. Windows), deleting a file will fail if the
+   file is still open.  By leaving it up to Python to decide when to
+   close a file, you may find yourself being unable to reliably delete
+   it.
+
+   The most reliable way to ensure that a stream is closed is to put
+   the call to `close()` in a `finally` block:
+
+     stream = file(somePath)
+     try:
+       ... do something with stream ...
+     finally:
+       stream.close()
+
 Testing
 =======
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20071212/e32b4586/attachment.html