Re: API/Code Documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 23 Jan 2008 17:49:01 -0500
Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:

> 
> > I guess we should figure out how we want our users to read the
> > documentation. Do we want them to look it up online, generate it
> > (resttext in docstrings), read the MODULES/README file, etc..
> >
> >   
> What we should do is work on fixing the modules and figure this out later :)

That works :-)

> >
> >
> > The only other option I see with that is to have very large amount of
> > possible keywords to modules that can take lots of options .... 
> 
> API signatures should most likely take dicts in those cases, and as we 
> go on we'll have more client side modules
> with much less reliance on "call" for the CLI.    We certaintly don't 
> want 12 positional arguments :)
> 
> >
> >
> > Agreed ... I think (shell wrapping) it's just the easiest thing to do
> > quickly and it is helpful enough to use. If we can deine some useful
> > items (esp from the current user base) that are not shell abstracting
> > we could jump on it quickly. The best ideas out there right now are
> > the system-config items and yum/rpm item that we could start working
> > through. I'll try to pick up on one or more of those modules.
> >   
> Anything new needs to be as API based as possible so that we do not 
> continue the trend, as it's gruntwork
> to clean up later that no one wants to do.     This should probably be a 
> priority to get this done
> before we expand the core too much.     Standardizing (or improving) the 
> returns (doing things that
> are key/value hash based -- complex data structures) versus splitting 
> shell lines should also be important, though
> as we do this we'll need to write the corresponding  features into 
> things like "show" so the CLI remains
> human readable (even though that is not the sole focus, it will be for 
> many people).

How about something as simple as ...

class FuncResponse(dict):
    def __getattr__(self, name):
        """
        Return attributes based on the dict.
        """
        return self[name]

    def __setattr__(self, key, value):
        """
        Setting attributes update the dict.
        """
        self[key] = value


We would get both attribute and dict access ... it would not be as complex as a multilevel hash, but, if we don't need all the power of a multilevel hash, I think it would be a good contender. I guess you could still do multilevel but it is a bit odd ...

f = FuncResponse(a=FuncResponse(b=True))
print f.a.b

or 

f = FuncResponse()
f.a = FuncResponse(b=True)
print f['a']['b']

> system-config is a bit complex and it would be worthwhile getting 
> everyone together for a quick
> hackfest/meeting for what we want to do about that.

Sounds good.

> (Obviously this leaves out some non-local IRC friends, but IRC doesn't 
> quite scale for SW design...)
> 
> >   
> >> I would much rather see that happen now than adding a bunch of
> >> documentation about how those commands work, especially as we are
> >> starting to see other applications start building themselves
> >> around Func.
> >>     
> >
> > My group already has a few :-)
> >   
> 
> Some of that may be a good fit for the Wiki?

I don't see why not :-).

-- 
"An organisation that treats its programmers as morons will soon have 
programmers that are willing and able to act like morons only."
    -Bjarne Stroustrup

_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux