[MERGE] checkout
Martin Pool
mbp at sourcefrog.net
Thu Mar 9 04:10:52 GMT 2006
On 13 Feb 2006, at 11:50 , Robert Collins wrote:
>>> import bzrlib
>>> +import bzrlib.branch as branch
>>> from bzrlib.branch import Branch
>>> import bzrlib.bzrdir as bzrdir
>>> from bzrlib.bzrdir import BzrDir
>>
>> Again, I would strongly discourange "import bzrlib.branch as branch"
>
> Waiting for your feedback above on this.
(Old thread)
I rather agree with John on discouraging importing modules with
partial names.
There are many operations which operate on "a branch" or "the
bzrdir", where there is just one thing and it provides the context
for the operation (without being self). There are a few options:
[1] say "a_bzrdir" or "the_branch"; this is OK but arguably a bit
wordy for a local name
[2] just "bzrdir" (iow just the noun without an article)
[3] some shorter abbreviation like "b" or "t", which is OK but
perhaps a bit too cryptic
[4] come up with a more specific meaning - but for this type of
variable there often isn't one
So my vote would be for [2], and when we want an explicit package
name to say bzrlib.bzrdir.Foo -- this makes it much more clear that
it really is a package.
>>>
>>> + def test_update_sets_last_revision(self):
>>> + # working tree formats from the meta-dir format and
>>> newer support
>>> + # setting the last revision on a tree independently of
>>> that on the
>>> + # branch. Its concievable that some future formats may
>>> want to
>>> + # couple them again (i.e. because its really a smart
>>> server and
>>> + # the working tree will always match the branch). So we
>>> test
>>> + # that formats where initialising a branch does not
>>> initialise a
>>> + # tree - and thus have separable entities - support
>>> skewing the
>>> + # two things.
>>
>> Since we disabled using the doc string instead of the test path when
>> using --verbose, we can use docstrings instead of comments. (There
>> are
>> other tests you added which can be changed as well)
>
> Other test runners such as the unittestgui will still show the
> docstrings. I think its cleaner to use comments when we are describing
> intention here.
Hm, I think I'd want the intention to be shown in the gui - so if it
fails you have a clue right away as to what it was trying to
exercise. Like any docstring it should be at the level of intention/
interface not implementation. But then I don't use unittestgui...
--
Martin Pool
More information about the bazaar
mailing list