Re: ANNOUNCE: python-apt

[Daniel Burrows <Daniel_Burrows@brown.edu>]

On Sat, Feb 19, 2000 at 10:04:40PM -0700, Jason Gunthorpe was heard to say:
> 
> On Mon, 14 Feb 2000, Daniel Burrows wrote:
> 
> >  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
> 
> Well, someday there may be a third structure ... Unless there is a way to
> add new ones in future easially it is probably best to keep them
> more seperate.

  Hm.  It may actually be easier to subsume the depcache into the package
iterators from this point of view.  If I make them separate structures I have
to maintain type objects and so on for them; if they just provide separate sets
of members, I can just tack extra cases onto the getattr function for
PkgIterator.

> > operation.  I could make them into sequences (as you suggested with the
> > version list), but this has the drawback that accessing an arbitrary member
> 
> Make a member for everything that can return lists of iterators, even
> though it is horribly inefficient, it is the Python Way. So you could do 
> 
> for i in Cache.Packages():
> 
> and for i in Pkg.Versions();
> 
> Remember, noboy is going to be using python because it is efficient, they
> want easy to understand :> Having the native iterators might be useful,
> donno..

  Right, but I'd like to avoid gratuitous inefficiency :)

  Currently I've decided to avoid having to artificially make the version
lists look like sequences and just return an honest-to-God tuple when the user
asks for the 'version' attribute.  I may at some point cache this in the
package, but it may not be worth it (I'll want to see how the various
objects get used in practice)

  Daniel

-- 
"Truly, you have a dizzying intellect."
  -- "The Princess Bride"