On Tue, 2008-12-02 at 19:55 +0100, Dirk Meyer wrote:
> > -Create doc in the Wiki and dump it into the doc subdir
>
> I started with it. Sadly, the Wiki has less doc than I remembered.
I thought by now everything in the wiki was moved into Sphinx docs, so
that's why I removed that line.
> > +- Eliminate explicit type() checking. Even isinstance() should be avoided
> > + where possible, relying instead of duck typing.
>
> I agree on the type stuff. But there are MANY type(s) and isinstance in
> the code. Why do you want to remove it?
It's going to have to be a case-by-case judgement call. In general
though, checking type (either with type() which sucks, or with
isinstance() which isn't much better) isn't very pythonic. That is to
say:
if isinstance(obj, Duck):
obj.quack()
else:
raise ValueError('obj must be a Duck')
is less pythonic than:
try:
obj.quack()
except AttributeError:
raise ValueError('obj must quack like a Duck')
The latter relies on duck typing.
There _are_ proper uses of isinstance() in our code, of course. I'm not
suggesting we get rid of everything, just that we evaluate these cases
on their merits.
> > +- Make sure SystemExit and KeyboardInterrupt is not silently caught. They
> > + should be bubbled up to the notifier loop. In other words, do not
> > + use catch-all except statements
>
> Agreed. I started with it some time ago. Are there still such cases in
> the code?
No idea.
> > but rather 'except Exception' (which
> > + will not catch KeyboardInterrupt and SystemExit).
>
> IIRC KeyboardInterrupt is an Exception in 2.4 but not anymore in 2.5. So
> for 2.4 we need catch KeyboardInterrupt, SystemExit and raise it again
> and catch the rest after that.
Indeed, I forgot about 2.4 :)
> > +- Rewrite of Process class
>
> Your job :)
Work in progress.
> > +- Complete documentation
>
> Every help welcome
I'll definitely help once the API has settled.
> > +TODO either before or after 1.0:
> > +- Unit testing suite (preferably before)
>
> I wanted it for a long time, but it is a huge task.
It is, but it's pretty important for kaa.base, which has some terribly
tricky code and is the foundation for everything we're doing. So good
unit testing will have big payoffs.
But it's enough work that we might not want to delay a 1.0 for it
(provided we accept the risk that a 1.0 may lack quality without unit
testing).
Jason.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
