2011/3/27 Ben Walton <bwal...@opencsw.org>:
> Excerpts from Maciej Bliziński's message of Sun Mar 27 04:18:42 -0400 2011:
>
>> I've recently learned a Python idiom for opening files:
>>
>> with open(obsoleted_by_path, "r") as fd:
>> indented block
>> using fd
>
> Ah! Very ruby-esque, I like it. The same thing in Ruby would be:
>
> File.open("/path/to/file", "r") do |file|
> file.each_line do |line|
> ...
> end
> end
>
> (I'm one of the folks that likes the 'end' block markers as I find
> they improve readability.)
Nothing prevents you from using them in Python:
end = None # define a name
for i in range(4):
for j in range(4):
print i, j
end
end
>> fd is unavailable outside that block
>
> Exactly the way it works in ruby too. This is much nicer for many of
> the typical file processing tasks that are common in code.
>
>> I expect that some packages might contain a file with bad syntax, e.g.
>> 3 fields or 1 field.
>
> Yes, a good point. I'm only using the first two fields, but there is
> a package description for the package that obsoletes the package too.
> Not sure it's much use in the tests though. We could forseeably
> change the description of a package in the future while not releasing
> the updated _stub packages for example. Thus, of the line with
> format:
>
> CSWfoo foo - The foo package is great
>
> We only care about the first two white space separated fields.
Agreed.
>> if 2 != len(fields):
>
> I prefer len(fields) != 2. Is there a reason you prefer the ordering
> above? If it's the more common ordering throughout the code, I'll use
> it for consistency.
If it was C, I would argue that 2 != len(fields) is better. In
Python, use what you feel is more readable.
Since we allow >2 fields: if len(fields) < 2: (...)
>> Or even better:
>> return {
>> "syntax": obsoleted_syntax_ok,
>> "by": obsoleted_by,
>> }
>
> I like this better too.
>
>> Next steps should be:
>>
>> - add a dict item around lib/python/package_stats.py line 500 (you
>> could add a tuple, or transform it into a dictionary, or use
>> whatever form that you think will be convenient to use later on; I
>> like dictionaries because they tend to be self-descriptive)
>
> I was looking at this last night but couldn't make the new info be
> displayed in the output of checkpkg_inspect_stats.py -p...
>
>> - since you're changing the data format, increment
>> PACKAGE_STATS_VERSION in package_stats.py (line 25)
>
> Ok, didn't catch that last night.
>
>> - use the new data structure in a check
>
> I think the first thing I'll do is ensure _stub when obsoleted by
> syntax is ok and the list isn't empty. There are many other checks
> that can focus on this new data. A list that isn't empty but fails
> the syntax check would be one such test.
You could also check package description: if it's a _stub, it needs to
declare that in the description; if it declares that in the
description, it needs to be a _stub.
> Updated patch attached.
I wouldn't mind inline patches, it would let me skip downloading, and
allow commenting inline.
Maciej
_______________________________________________
devel mailing list
devel@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/devel
