|
16 | 16 |
|
17 | 17 | <div class="sidebar">
|
18 | 18 | <div class="doclist">
|
19 |
| - <a href="usersguide.htm">User's Guide</a><br/> |
20 |
| - <a href="customizing.htm">Customization Guide</a><br/> |
21 |
| - <a href="hardware.htm">Hardware Guide</a><br/> |
22 |
| - <a href="utilities.htm">Utilities Guide</a><br/> |
23 |
| - <a href="upgrading.htm">Upgrade Guide</a><br/> |
24 |
| - <a href="devnotes.htm">Notes for Developers</a> |
| 19 | + <a href="usersguide.htm">User's Guide</a><br/> <a href="customizing.htm">Customization Guide</a><br/> <a |
| 20 | + href="hardware.htm">Hardware Guide</a><br/> <a href="utilities.htm">Utilities Guide</a><br/> <a |
| 21 | + href="upgrading.htm">Upgrade Guide</a><br/> <a href="devnotes.htm">Notes for Developers</a> |
25 | 22 | </div>
|
26 | 23 | <div id="toc_controls"></div>
|
27 | 24 | <div id="toc_parent">
|
|
52 | 49 |
|
53 | 50 | <h1>Goals</h1>
|
54 | 51 |
|
55 |
| - <p>The primary design goals of <span class="code">weewx </span>are: </p> |
| 52 | + <p>The primary design goals of <span class="code">weewx</span> are:</p> |
56 | 53 | <ul>
|
57 | 54 | <li>Architectural simplicity. No semaphores, no named pipes, no inter-process communications, no complex
|
58 | 55 | multi-threading to manage.
|
@@ -103,7 +100,7 @@ <h1>Strategies</h1>
|
103 | 100 | seems to be dead). Fortunately, Cheetah seems to be very robust, with only a few well-known bugs that
|
104 | 101 | are easiy worked around, so we will likely continue to use it for the foreseeable future.
|
105 | 102 | </li>
|
106 |
| - <li>Pure Python. The code base is 100% Python &mdash no underlying C libraries need be built to install |
| 103 | + <li>Pure Python. The code base is 100% Python — no underlying C libraries need be built to install |
107 | 104 | <span class="code">weewx</span>. This also means no Makefiles are needed.
|
108 | 105 | </li>
|
109 | 106 | </ul>
|
@@ -156,7 +153,11 @@ <h1>Units</h1>
|
156 | 153 | <h1>Value "<span class="code">None</span>"</h1>
|
157 | 154 |
|
158 | 155 | <p>The Python special value <span class="code">None</span> is used throughout to signal a missing data point.
|
159 |
| - All functions expect it. </p> |
| 156 | + All functions must be written to expect it. </p> |
| 157 | + |
| 158 | + <p>Device drivers should be written to emit <span class="code">None</span> if a data value is bad (perhaps |
| 159 | + because of a failed checksum). If the hardware simply doesn't support it, then the driver should not emit a |
| 160 | + value at all.</p> |
160 | 161 |
|
161 | 162 | <p>However, the time value must never be <span class="code">None</span>. This is because it is used as the
|
162 | 163 | primary key in the SQL database. </p>
|
@@ -187,6 +188,44 @@ <h1>Time</h1>
|
187 | 188 | next_ts = int(time.mktime(next_dt.timetuple()))</pre>
|
188 | 189 | <p>Other time conversion problems are handled in a similar manner. </p>
|
189 | 190 |
|
| 191 | + <h1>Internationalization</h1> |
| 192 | + <p>Generally, weewx does not make much use of Unicode. This is because the Python 2.x libraries do not always |
| 193 | + handle it correctly. In particular, the function <span class="code">time.strftime()</span> completely fails |
| 194 | + when handed a Unicode string with a non-ASCII character. As this function is often used by extensions, |
| 195 | + working around this bug is an unfair expectation on extension writers. So, we generally avoid Unicode.</p> |
| 196 | + <p>Instead, weewx mostly uses regular strings, with any non-ASCII characters encoded as UTF-8. </p> |
| 197 | + <p>An exception to this general rule is the image generator, which holds labels internally in Unicode, because |
| 198 | + that is the encoding expected by most fonts.</p> |
| 199 | + <p>The document <i><a |
| 200 | + href="https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/">The |
| 201 | + Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character |
| 202 | + Sets</a></i> by Joel Spolsky, is highly recommended if you are just starting to work with UTF-8 and Unicode. |
| 203 | + </p> |
| 204 | + |
| 205 | + <h1>Exceptions</h1> |
| 206 | + <p>In general, your code should not simply swallow an exception. For example, this is bad form:</p> |
| 207 | + <pre class="tty"> |
| 208 | + try: |
| 209 | + os.rename(oldname, newname) |
| 210 | + except: |
| 211 | + pass |
| 212 | + </pre> |
| 213 | + <p>While the odds are that if an exception happens it will be because the file <span class="code">oldname</span> |
| 214 | + does not exist, that is not guaranteed. It could be because of a keyboard interrupt, or a corrupted file |
| 215 | + system, or something else. Instead, you should test explicitly for any expected exception, and let the rest |
| 216 | + go by:</p> |
| 217 | + <pre class="tty"> |
| 218 | + try: |
| 219 | + os.rename(oldname, newname) |
| 220 | + except OSError: |
| 221 | + pass |
| 222 | + </pre> |
| 223 | + <p>Weewx has a few specialized exception types, used to rationalized all the different types of exceptions that |
| 224 | + could be thrown by the underlying libraries. In particular, low-level I/O code can raise a myriad of |
| 225 | + exceptions, such as USB errors, serial errors, network connectivity errors, <i>etc.</i> All device drivers |
| 226 | + should catch these exceptions and convert them into an exception of type <span |
| 227 | + class="code">WeeWxIOError</span> or one of its subclasses.</p> |
| 228 | + |
190 | 229 | <h1>Glossary</h1>
|
191 | 230 |
|
192 | 231 | <p>This is a glossary of terminology used throughout the code. </p>
|
|
0 commit comments