Ah cool idea for using a variable for the index value. I'll look to do
that where it can be employed. That certainly clarifies one of the more
confusing things of using lists!
Thank you,
Clay
On Wed, 16 Sep 2009, Jack Schwartz wrote:
> Hi Clay.
>
> Missed a few XXX I had marked before hitting send...
>
> On 09/16/09 15:31, Jack Schwartz wrote:
>>>
>>>> /usr/src/cmd/installadm/delete-service.py
>>>> -----------------------------------------
>>>>> 203: Seems like either removeFile should march on when an error occurs
>>>>> (for
>>>>> more complete processing), or else the callers to removeFile should stop
>>>>> processing when removeFile encounters an error. The current solution is
>>>>> not
>>>>> complete on errors.
>>>>
>>>> Why is this not complete? It keeps processing on errors as do its callers
>>>> and callees.
> OK. Yes you are correct.
>
> You may want to get rid of the extra returns at 227, 231 and 232 as they are
> not needed. I think they add noise, but if you disagree and think they add
> clarity then leave them in.
>>
>>>
>>>> 279: I would like to see names for field indeces, instead of hardwired
>>>> numbers.
>>>> This makes the code less prone to breakage if the fields change for some
>>>> reason.
>>>
>>> Unfortunately, split doesn't let one name each split record. I can update
>>> the comment above to give an example txt_record string (i.e. "split on :
>>> as the string txt_record should be hostname:port"), however, to give a
>>> better comprehension to a reader what is being provided.
> OK. That works for me.
>
> That said, one can define and use variables with a value representing what an
> index represents, instead of hardwiring index values. I did something like
> this in the finalizer. Example:
>
> _fs_type, _fs_module, _fs_arglist = range(3)
>
> initializes _fs_type to 0, _fs_module to 1 and _fs_arglist to 2.
>
> Thanks,
> Jack
>
