On Mon, 2005-07-11 at 13:30 +0200, Dirk Meyer wrote: > Yes, we should find a max width for all kaa modules, Python and C > files. Right now my emacs works with 92 chars, I try to only use > 80. 130 is very much, close to the maximum I can use on my laptop > (it's about 135 chars with my current font).
My laptop does 1600x1200. I won't buy a laptop that has a lower
resolution for the very reason that I work with a lot of terms open.
http://sault.org/~tack/hacking.jpg
(The code in the upper left corner is the new canvas api I'm working on
that will have a similar architecture to mevas.)
80 is little, but 92 isn't a big gain over that. My main concern is
that hard-breaking a long line to multiple lines often decreases
readability even when compared to a long line that wraps.
> I hope I only use chars, maybe it was a mix up with your code? Or
> maybe I have tabs in C files, I'm not sure. About the future: we
> should only use spaces. A space has a fixed width, tabs may differ. So
> I vote for spaces.
It's possible I had some tabs left in there, but it looks like wherever
you wrapped long lines (a function definition, say) you used tabs to
align the new line. Anyway I've committed a fix.
> Yes, I also don't like it. But this we only wrap, we could set
> | add_timer = addTimer
> or we change it during import. The nf_generic has addTimer and we
> rename it internal in kaa.notifier to add_timer. I agree, we should
> keep one style and this style should be functions_like_this and
> ClassLikeThis.
I think however we do it, they should get renamed to follow the style
guide. I'll defer to your better judgement. :)
> I wrote a coding standard for Freevo in the wiki:
> http://freevo.sourceforge.net/cgi-bin/doc/CodingStandard
Yes, I agree with almost everything here except for the 80 column limit.
When I write code for my own project, I get to pick my own style. If my
terms are 130 columns wide, I want to use that space. :) But if yours
are only 80, then we'll use 80. The extra space makes a big difference
IMHO, but if you're limited by resolution, I don't want to write code
that looks ugly for other project members.
> the logging module and not print" and "don't import more than one
> module in a line". We can discuss about it, but we need one way how to
Disagree on this point. I'd say you can use one line to import multiple
modules from a single source, where source is either "system modules" or
a specific module. i.e.:
import sys, os, select, string
import notifier
from kaa import imlib2, display, evas
from freevo import foo, bar, baz
What's wrong with that?
> code. The 80 chars is still up to discussion. And I also prefer
> 'string' over "string".
My arguments for double quotes are:
1. It's that way in C, and I code a lot of C as well as python for
kaa. So strings are represented consistently.
2. Escaping characters (\) uglifies the string. You're more likely
to want to put a single quote (apostrophe) in a string than a
double quote. i.e. "You're more likely to do this" as 'opposed
to "this"'.
If you want to use the "visual clutter" argument, I'd say having an
escape character in a string makes that much more cluttered than double
quotes. So I would argue that the choice for double/single quotes
should depend on the contents of the string in order to avoid escaping,
where the default is double quotes because that's how it is in C, which
is the second language of kaa. :)
> First of all: maybe we can use more than 80 chars in the code, but
> please do not use more than 80 in the cvs log. It's ugly to read that
> way because the cvs mailer breaks at 80 chars.
That was anomalous. You've seen my past cvs logs and know I usually
wrap before column 80. It won't happen again. I promise I'll be good.
Please don't hurt me anymore daddy.
> we could use
>
> |
> gui.display._window.signals[kaa.display.KEY_PRESS_EVENT].connect(self.handle)
>
> It's safer, maybe I make a misstake when writing the signal name. A
> simple string would just fail and I search for the problem. If it is a
> variable, Python will cry out and I see the bug.
Arguments against:
1. The current approach is familiar to gtk+ users.
2. The current approach is more readable (perhaps subjective).
3. Your suggestion makes lines even longer. Indent your suggestion
a few levels and break it up to fit on 80 columns and tell me
whose is more readable. :)
4. Even if you mess up the signal name string, you get a KeyError
exception. Yours would be AttributeError. The exception would
occur at the same spot in the code execution. So yours has no
benefit (unless you can argue the different exception type is
beneficial somehow).
> And what is getch? What is it used for? And maybe we should move the
getch() is used for console apps so you can get key presses on stdin
like the way it works with mplayer. I need to rewrite that code so it
hooks into notifier. It's a handy little function to have around.
> utf8 code into a stringutils or similar file. I also have some string
> functions I need to add.
If you want to add more functions, putting this into a stringutils file
sounds fine.
> Thanks. After fixing a bug in the plugin loader (the plugin had no
> reference so your weakref code let the plugin go into the free space
> again) it works. Great, looks much better now.
My weakref code? Which code? If you're talking about
check_weakref/make_weakref in kaa.base.utils, I think that should go
away to be succeeded by kaa.base.weakref,
> There was one reason this is no object in freevo. IIRC something
> crashed with __getattr__. I'm not sure, I will test this with freevo
> to check if it is a problem or not.
Yes, let me know. Proxying __class__ so that isinstance() will Just
Work for proxied objects is important. Only way to do this is to use
__getattribute__.
> And I tried evas. Nice. I hope to see a more complex example + fb/dfb
> displays in the near future.
I'm working on a higher level API for evas that's mevas-like. I'll
commit what I have soon, although it's in the very early stages.
Jason.
signature.asc
Description: This is a digitally signed message part
