Hi, seth!
>>>>> "sv" == seth vidal <skvidal@xxxxxxxxxxxx> writes:
sv> I'm not going to respond to each individual point, but I will give my
sv> general view:
;)
sv> I do have to read all the patches that you send me b/c I _HAVE_ to
sv> read them. I won't apply a patch w/o reading an understanding it so if
sv> it seems like I'm taking a while its b/c I'm busy with other things.
I think, 'reading and understanding before applying' is the only right way.
No problem if other things has priority.
sv> 2. The reason a lot of functions have import module at the beginning
sv> of them is b/c I moved stuff around quite a bit. So I figured if I
sv> could cut and paste the module w/little or no modification then it
sv> made the function more easily used for me or for other things.
I comment this later, if you please ;)
At that time, we skip discussion about "where place import" ;)))
sv> 3. I am not a full time programmer, I've never had any formal training
sv> in programming save one class. I maintain a large number of linux
sv> systems for a living and it probably shows in my code. I'm a sysadmin
sv> who happens to end up doing a lot of weird stuff. Having said that, I
sv> don't find it horribly unreadable code so I'm not sure how much
sv> benefit comes from some of the modifications suggested in the style
sv> guides.
I am a full time programmer. And I know, programming is easy science.
You can do any other work and as hobby - write nice programms. Not worse
than experts ;)
Code Styling - first step. It's not dogma. Any programming language has
"style". With some languages (like C) we can apply a number of styles.
Proffesional programmer know "how and why" styling help in development.
You can just use Guido's style, understanding comes with experience.
If sometimes I don't understand "how write code better", I do "like Guido
say". And never get troubes. Maybe because GvR one of most expirienced
python programmers ;-)
sv> 4. Regarding additional classes. I can see a couple of places where an
sv> additional class would be handy but I've not seen a lot of them.
My instructor once has told: "correct way - evolution, not revolution".
IMHO, we all like small development iterations. For beginning enough
one place where we can "do better".
sv> Arguments persuading me to remove all functions outside of classes are
sv> going to need to be DAMNED impressive. I'm not always taken by
sv> additional classes. Frequently, I find they do a lot for abstraction
sv> but they also do A LOT for obfuscation.
Of course, classes only for better abstraction and understanding. No
obfiscuration ;)
sv> MANY MANY MANY classes make it hard for non-programmers to begin to
sv> understand the code, and given that this code is for a utility that A
sv> LOT of sysadmins could use it would seem to me to be useful to make
sv> sure that they can understand it.
I agree. But how many ppl can understand code like this:
(e1, v1, r1) = rpmNevral.evr(name, arch)
(e2, v2, r2) = str_to_version(obvalue[3])
rc = compareEVR((e1, v1, r1), (e2, v2, r2))
what they can do:
1. track up source, what we hold in 'obvalue'. Suprize!
for ob in obs:
obvalue = string.split(ob)
2. track up source, from where we get 'obs'...
3. ...
eeehhh... Me don't like criticize.
Just small example ('code from head', not tested, simple an idea), how
'for ob in obs:' must look:
for package in obsoletes:
if rpmNevral.has(package.name):
if rpmNevral[package.name].obsoleting(package):
packages.append(package)
obsdict[package] = package.name
log(4, '%s oblsoleting %s' % (package.name, package))
more than 50 lines (more than two screens at standard text console) of
code moved out into 'obsoleting' method of some 'abstraction'. One action
and one loging for all 15 "obsoleting or no?" varinats (3 result codes, 5
comparisons). No duplicates and no mistakes.
btw, I don't understand what for to us 'packages' in returnObsoletes?
At start we say packages = []. Inside, we only append to them some
(name, arch). At final, we return obsdict. Anywhere in clientStuff
'packages' not used.
How 'not expirienced guy' can understand 'for what we use packages? What
here magick?
Nice casual illustration? ;)
sv> I'm not wed to this concept in anyway, and I might be more than glad
sv> to get rid of it and add in a bunch of classes. But I learned how to
sv> program mostly in perl and some C, so I'm more comfortable with
sv> procedural programming.
it's not a problem ;)
sv> Object Orientation is great for some things but I know what the old
sv> yup code looked like and I'm a little afraid of "object orienting" to
sv> that extent.
We shall help You to not be afraid OO-code ;)
sv> 5. I'm using this program everyday on quite a few systems and the
sv> reason I didn't go with apt-rpm was that I wanted to completely
sv> understand what the code was doing when it did it, so if I'm slow in
sv> integrating patches its b/c I'm thinking about them and making sure I
sv> understand them.
Once more "yes". Ease of understanding - primary target. If some code
modification will complicate understanding, just say "we go in a wrong
direction".
sv> So, in summary, I am reading through all the emails regarding style
sv> and I'll address them as soon as I can. (refer to my last email about
sv> the broken hard drive :)
I wish the quickest decision a problem with a hard drive.
sv> I'd like to make it cleaner looking but it is possible that your
sv> concept of cleaner and my concept of cleaner might not gibe.
Two persons always will come to agreement if they want it ;)))
--
Bor.
