[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