Re: ANNOUNCE: python-apt

[Daniel Burrows <Daniel_Burrows@brown.edu>]

On Sun, Feb 13, 2000 at 10:22:08PM -0700, Jason Gunthorpe was heard to say:
> >   Hello, all.  I've started working on Python bindings for the APT libraries.
> > I've gotten enough done to have a somewhat useful preliminary version which
> 
> Ooh, I've wanted someone to do this for such a long time! Congrats.
> 
> Would you mind writing up a document describing how you want your
> interface to work? 

  Hmm, good idea :)  I'll try to do that this week.

> For this to be quite usefull it needs a good natural python interface,
> probably one that doesn't exactly match the C++ one - that was built for
> efficiency not ease of use.

  Yep.  I'm trying to avoid mirroring C++ too much, but since this is my
first Python extension I was concentrating a little more up to this point on
just getting it to work with any interface.  I'll probably want to juggle
things as I go on..

> For instance, I'd instantiate a records parser at the start and make it
> implicitly available when you do things like:
> 
> Cache.Pkgs['dpkg'].Versions[0]["Description"] 
> 
> (evil!)
> 
> That seems like a natural sort of interface to have..

  That looks like a good way to handle things..I think it may also (?) be a good
idea to not separate the state cache information and the package iterators..
right now you have to do:

i=Cache.Pkgs['dpkg']
state=Cache.Pkgs[i]

 to see state.installed, and so on.  But I don't think there's any reason not
to merge these two structures so you can directly access, say,
Cache.Pkgs['dpkg'].mode

  Another thing I'm wondering about is the iterators -- right now I've wrapped
them pretty straightforwardly, substituting a 'next' member for the increment
operation.  I could make them into sequences (as you suggested with the
version list), but this has the drawback that accessing an arbitrary member
in Python would be O(n) and iterating over the list in a 'for' loop would
be O(n^2) (normal Python sequences are just arrays, so it's expected that
those operations will be O(1) and O(n))  OTOH, "for i in package.versions" is
a pretty nice way to do things.

  Maybe I should provide that interface and put a warning on it that it's not
efficient for long lists, so (eg) iterating over the entire package cache like
that is a bad idea..

  Daniel

-- 
  A conclusion is the place where you got tired of thinking.