← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/code-style.txt

  • Committer: Richard Wilbur
  • Date: 2016-02-04 19:07:28 UTC
  • mto: This revision was merged to the branch mainline in revision 6618.
  • Revision ID: richard.wilbur@gmail.com-20160204190728-p0zvfii6zase0fw7
Update COPYING.txt from the original http://www.gnu.org/licenses/gpl-2.0.txt  (Only differences were in whitespace.)  Thanks to Petr Stodulka for pointing out the discrepancy.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/code-style.txt
77
77
Python versions
78
78
===============
79
79
 
80
 
Bazaar supports Python from 2.4 through 2.6, and in the future we want to
81
 
support Python 2.7 and 3.0.  Avoid using language features added in 2.5,
82
 
2.6 or 2.7, or features deprecated in Python 3.0.  (You can check v3
 
80
Bazaar supports Python from 2.6 through 2.7, and in the future we want to
 
81
support Python 3.  Avoid using language features added in
 
82
2.7, or features deprecated in Python 3.0.  (You can check v3
83
83
compatibility using the ``-3`` option of Python2.6.)
84
84
 
85
 
Specifically:
86
 
 
87
 
* Don't use the ``with`` statement.
88
 
 
89
 
* Don't ``from . import``.
90
 
 
91
 
* Don't use ``try/except/finally``, which is not supported in Python2.4,
92
 
  use separate nested ``try/except`` and ``try/finally`` blocks.
93
 
 
94
85
 
95
86
hasattr and getattr
96
87
===================
189
180
   why in a comment.
190
181
 
191
182
1. Never rely on a ``__del__`` method running.  If there is code that
192
 
   must run, do it from a ``finally`` block instead.
 
183
   must run, instead have a ``finally`` block or an ``addCleanup`` call an
 
184
   explicit ``close`` method.
193
185
 
194
186
2. Never ``import`` from inside a ``__del__`` method, or you may crash the
195
187
   interpreter!!
196
188
 
197
 
3. In some places we raise a warning from the destructor if the object
198
 
   has not been cleaned up or closed.  This is considered OK: the warning
199
 
   may not catch every case but it's still useful sometimes.
200
 
 
 
189
3. Prior to bzr 2.4, we sometimes used to raise warnings from del methods
 
190
   that the object was not cleaned up or closed.  We no longer do this:
 
191
   failure to close the object doesn't cause a test failure; the warning
 
192
   appears an arbitrary long time after the problem occurred (the object
 
193
   being leaked); merely having a del method inhibits Python gc; the
 
194
   warnings appear to users and upset them; they can also break tests that
 
195
   are checking what appears on stderr.
 
196
   
 
197
In short, just don't use ``__del__``.
201
198
 
202
199
Cleanup methods
203
200
===============