1 |
On Tue, Feb 10, 2009 at 2:53 AM, Douglas Anderson <dja@××××××.com> wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> It's been a few months since we first discussed refactoring equery on |
5 |
> this list and I think made pretty good time and I'm reasonably happy |
6 |
> with it. So I'm throwing out to you all. I've tried to keep a running |
7 |
> list of visible changes as I went along, but I'm sure I've missed some |
8 |
> things. You can read that here: |
9 |
> |
10 |
> http://code.google.com/p/genscripts/source/browse/equery/trunk/equery/CHANGELOG |
11 |
> |
12 |
> My primary goals for the refactorization were: |
13 |
> * Modularize |
14 |
> * Clean up the UI |
15 |
> * Rewrite a more solid option handler |
16 |
> * Eliminate as much duplicated code as possible |
17 |
> * Clean up slop and bitrot, follow clean coding standards and style |
18 |
> guidelines wherever possible |
19 |
> * Break up large functions, write docstrings for all functions |
20 |
> * Get code set for Python 2.6 (tested in 2.5 and 2.6) and prepare |
21 |
> smooth upgrade for Py3k. |
22 |
> * Create a more consistent experience for the user. |
23 |
> |
24 |
> This last point is surely where the most contention will stem from, so |
25 |
> let me argue my position. All modules except for list, check and size |
26 |
> display the help message when called without input (ex: equery uses). |
27 |
> This makes sense. It's what most other programs do. It's what emerge |
28 |
> does. It's what eselect does. It's the neighborly thing to do. |
29 |
> |
30 |
> However these three exceptions go and start a time-consuming process |
31 |
> which is of very limited usefulness. With a cold cache, each process |
32 |
> takes at least 30 seconds. I imagine that 99 percent of people who |
33 |
> type 'equery list' do it by accident. And who needs to see the size of |
34 |
> every installed package? And checksum every installed package? Almost |
35 |
> useless except to a select few people who know what they're doing. |
36 |
> |
37 |
> So I took the liberty of changing the default behavior of these three |
38 |
> modules to be more in line with the rest of equery and the world. Each |
39 |
> of the three displays deprecation warning explaining how to recreate |
40 |
> the old default behavior. I can't imagine anyone objecting outright to |
41 |
> this, considering there will always be more than one version of |
42 |
> gentoolkit in the tree (there are 6 now) so it'd be a long time before |
43 |
> anyone was forced into the new behavior. |
44 |
> |
45 |
> That's it. For anyone interested, please read the link above and let |
46 |
> me know if you like it/hate it/want something else done. |
47 |
> |
48 |
> For python programmers, I'd appreciate a quick code review and any |
49 |
> comments/criticism whatsoever (I really like criticism). |
50 |
|
51 |
You Asked... |
52 |
|
53 |
I think one of the major things that annoyed me when reading the code |
54 |
is that you did add a new option parser...and you added it about a |
55 |
dozen times...(regexp used to basically find the start of the same |
56 |
code block over and over). |
57 |
|
58 |
antarus@kyoto ~/code/checkouts/genscripts-read-only/equery $ grep |
59 |
"opts = .x" *.py | wc -l |
60 |
13 |
61 |
|
62 |
Now the option parsing is quite complicated so I'm not sure if a |
63 |
complicated data structure to pass to a generic function is really a |
64 |
good use of ones time. But it stands out. |
65 |
|
66 |
None of your files has a copyright notice. |
67 |
|
68 |
I pray pp.print_error prints to stderr and not stdout; otherwise tends |
69 |
to be a big nitpick of mine when people write errors to stdout. |
70 |
|
71 |
belongs.py has this gem: |
72 |
q.append(('^' if query[0] == '/' else '/') + re.escape(query) + '$') |
73 |
|
74 |
I realize it works; but honestly, not readable. |
75 |
|
76 |
append_str = "" |
77 |
if query[0] == '/' append_str += '^' else append_str += '/' |
78 |
append_str += re.escape(query) + '$' |
79 |
q.append(append_str) |
80 |
|
81 |
Slightly better (if append_str has a shorter name, maybe). I don't |
82 |
like 1 line if EXPR STATEMENT else STATEMENT but sometimes they are |
83 |
shorter |
84 |
Putting a conditional in the function call is horrible looking though. |
85 |
|
86 |
You use # FOO comments often; sometimes too often. Explaining what |
87 |
you are doing is typically better noted in a docstring for a function |
88 |
and not necessarily right next to the code it pertains to. An example |
89 |
would be meta.py in get_useflags. You have a 4 line comment block |
90 |
describing what you are doing but it really interferes with the |
91 |
reading of the code. Functions should typically be short enough that |
92 |
referring to the docstring is no big deal (and the example I chose is |
93 |
a very short function). In addition you have a lot of "# do something |
94 |
obvious here." If it is obvious; you don't need a comment. An |
95 |
example of this would be meta.py around line 418. |
96 |
|
97 |
in __init__.py your find_matches function is too long (180 lines or |
98 |
4.5 of my screen heights). You've already split it up into convenient |
99 |
sections by comments (which are fine by the way) but you can probably |
100 |
make subroutines out of some of the subsections. Also most of the |
101 |
code has nothing to do with finding matches and lots to do with query |
102 |
preparation. |
103 |
|
104 |
in __init__.py you have InvalidRegex with a TODO to move it to another |
105 |
file. It seems like exceptions.py might be a worthy place. |
106 |
|
107 |
I think there are a number of cases where I'd prefer to see string |
108 |
interpolation instead of explicit addition: |
109 |
|
110 |
'%s/%s' % (cat, package) |
111 |
|
112 |
But thats just me being picky (and you use string interpolation often, |
113 |
which is good). |
114 |
|
115 |
Thats what I found in about 20 minutes of looking. |
116 |
|
117 |
-Alec |
118 |
|
119 |
> |
120 |
> Thanks in advance, |
121 |
> -Doug |
122 |
> |
123 |
> |