← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to HACKING

- refactor handling of short option names

Show diffs side-by-side

added added

removed removed

Lines of Context:
HACKING
119
119
(not ``x2y`` as occurs in some old code.)
120
120
 
121
121
 
122
 
Destructors
123
 
-----------
124
 
 
125
 
Python destructors (``__del__``) work rather differently from in other
126
 
languages.  In particular, bear in mind that destructors may not be called
127
 
immediately when the object apparently becomes unreferenced, and that
128
 
there are tight restrictions on what can be done inside them.
129
 
 
130
 
 0. Never use a __del__ method without asking Martin/Robert first.
131
 
 
132
 
 1. Never rely on a ``__del__`` method running.  If there is code that
133
 
    must run, do it from a ``finally`` block instead.
134
 
 
135
 
 2. Never ``import`` from inside a ``__del__`` method, or you may crash the
136
 
    interpreter!!
137
 
 
138
 
 3. In some places we raise a warning from the destructor if the object
139
 
    has not been cleaned up or closed.  This is considered OK: the warning
140
 
    may not catch every case but it's still useful sometimes.
141
 
 
142
 
 
143
122
Writing output
144
123
==============
145
124
 
199
178
Errors and exceptions
200
179
=====================
201
180
 
202
 
Errors are handled through Python exceptions.  They can represent user
203
 
errors, environmental errors or program bugs.  Sometimes we can't be sure
204
 
at the time it's raised which case applies.  See bzrlib/errors.py for 
205
 
details on the error-handling practices.
 
181
[write me]
206
182
 
207
183
 
208
184
Jargon
212
188
    Integer identifier for a revision on the main line of a branch.
213
189
    Revision 0 is always the null revision; others are 1-based
214
190
    indexes into the branch's revision history.
215
 
 
216
 
:: vim: tw=74 ai