patch: more sftp unit tests

John Arbash Meinel john at arbash-meinel.com
Tue Jan 10 18:54:47 GMT 2006


Robey Pointer wrote:
> 
> On 10 Jan 2006, at 6:55, Wouter van Heyst wrote:
> 
>> <snip>
>>
>> No pprinting when dumping? I can live with that, but perhaps both  would
>> be nice.
> 
> 
> The pprint output is huge, so IMHO you really want one or the other, 
> but not both.
> 
>>
>>> -    for a in argv:
>>> +    argv_copy = []
>>> +    i = 0
>>> +    while i < len(argv):
>>> +        a = argv[i]
>>>          if a == '--profile':
>>>              opt_profile = True
>>>          elif a == '--lsprof':
>>>              opt_lsprof = True
>>> +        elif a == '--lsprof-file':
>>> +            opt_lsprof_file = argv[i + 1]
>>> +            i += 1
>>>          elif a == '--no-plugins':
>>>              opt_no_plugins = True
>>>          elif a == '--builtin':
>>> @@ -501,9 +514,10 @@
>>>          elif a in ('--quiet', '-q'):
>>>              be_quiet()
>>>          else:
>>> -            continue
>>> -        argv.remove(a)
>>> -
>>> +            argv_copy.append(a)
>>> +        i += 1
>>> +
>>> +    argv = argv_copy
>>
>>
>> Why not just use something like:
>>
>>   for a in in list(argv):
>>     argv.remove(a)
> 
> 
> The previous version had a bug, which I forgot to mention last time:  By
> removing the item as it was being iterated, the loop actually  ended up
> skipping the next option.  (Meaning for instance, "--profile 
> --no-plugins" didn't work.)
> 
> I'm not overly fond of the "i" index loop, but I wanted to read the 
> filename arg, and you can't really do that from within "for a in".  
> Feel free to change that loop entirely; it made me make unhappy faces 
> when I was writing the patch.  I'm not sure why we don't just use 
> optparse.
> 
> robey

Our biggest problem is having 2 levels of options.
optparse really isn't sufficient for all the stuff we want to do at the
command level. Because we want to only allow certain options to exist at
that point, optparse usually wants to read them all at once.
I think optparse is just fine at the global-options level.
At one point I implemented a similar structure for parsing global
options before command options, but it was deemed too complex, because
we didn't have that many global options.
Also, my change assumed global options occured before the command (so
you would have 'bzr --no-plugins foo', not 'bzr foo --no-plugins')

Anyway, I would like to see something like optparse* handle the global
options, and then we could hand off everything else to the current
option parser.

John
=:->

* optparse probably won't do what we want, but just something more
systematic than iterating over the arguments in a large if/then structure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060110/96d4974e/attachment.pgp 


More information about the bazaar mailing list