80
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
83
compatibility using the ``-3`` option of Python2.6.)
81
support Python 3.0. Avoid using language features added in 2.5 or 2.6, or
82
features deprecated in Python 3.0. (You can check v3 compatibility using
83
the ``-3`` option of Python2.6.)
101
101
if getattr(thing, 'name', None) is None
107
``**kwargs`` in the prototype of a function should be used sparingly.
108
It can be good on higher-order functions that decorate other functions,
109
such as ``addCleanup`` or ``assertRaises``, or on functions that take only
110
(or almost only) kwargs, where any kwargs can be passed.
112
Otherwise, be careful: if the parameters to a function are a bit complex
113
and might vary over time (e.g. the ``commit`` API) then we prefer to pass an
114
object rather than a bag of positional and/or keyword args. If you have
115
an arbitrary set of keys and values that are different with each use (e.g.
116
string interpolation inputs) then again that should not be mixed in with
117
the regular positional/keyword args, it seems like a different category of
121
Imitating standard objects
122
==========================
124
Don't provide methods that imitate built-in classes (eg ``__in__``,
125
``__call__``, ``__int__``, ``__getitem__``) unless the class you're
126
implementing really does act like the builtin class, in semantics and
129
For example, old code lets you say ``file_id in inv`` but we no longer
130
consider this good style. Instead, say more explicitly
131
``inv.has_id(file_id)``.
133
``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
365
333
Because repr methods are often called when something has already gone
366
334
wrong, they should be written somewhat more defensively than most code.
367
They shouldn't have side effects like doing network or disk
369
335
The object may be half-initialized or in some other way in an illegal
370
336
state. The repr method shouldn't raise an exception, or it may hide the
371
337
(probably more useful) underlying exception.
387
353
``Exception`` (which excludes system errors in Python2.5 and later) would
390
The ``__str__`` method on exceptions should be small and have no side
391
effects, following the rules given for `Object string representations`_.
392
In particular it should not do any network IO, or complicated
393
introspection of other objects. All the state needed to present the
394
exception to the user should be gathered before the error is raised.
395
In other words, exceptions should basically be value objects.
495
454
* Don't say "open source" when you mean "free software".
501
If you need to import a module (or attribute of a module) named in a
504
* If importing a module, not an attribute, and the module is a top-level
505
module (i.e. has no dots in the name), then it's ok to use the builtin
506
``__import__``, e.g. ``__import__(module_name)``.
507
* In all other cases, prefer ``bzrlib.pyutils.get_named_object`` to the
508
built-in ``__import__``. ``__import__`` has some subtleties and
509
unintuitive behaviours that make it hard to use correctly.
512
457
vim: ft=rst tw=74 ai