On 7/22/05, Matt Wilson <msw@xxxxxxxxx> wrote: > On Fri, Jul 22, 2005 at 07:09:10PM -0300, Ulisses Furquim wrote: > > - pylibparted has a cleaner way of creating objects > > Changing the constructors around is pretty. I changed it around > several times before it landed the way it is now. Adding an interface > that is more palatable to you, while retaining a compatibility > interface for the people who use the interface as-is would be an > option. I'm not sure I understood what you meant.. Do you mean pylibparted should have PedDevice.get() and PedDisk.new(), for example? > > - pylibparted has some functions in different objects than the > > libparted API says (why? because I thought it was better for actually > > doing OO programming with pylibparted) > > I think this is actually a drawback that could confuse users familiar > with the C API. I don't think this can confuse users familiar with the C API. pyparted already changes the location of some functions. pylibparted only improves on that. :-) > > - pyparted doesn't have a way to probe all devices (you have to use > > a static method of PedDevice to actually create a PedDevice object for > > your device!) > > We always implemented this in application-specific code, since many > users of pyparted have their own hardware detection code that handles > cases that ped_device_probe_all() misses. Ok, so users can always use their own hardware detection code and do pylibparted.PedDevice(devicepath) to create a PedDevice object for each device they found. > > - with pylibparted you don't iterate through lists with a *_next_* > > method, because pylibparted returns a list where a list should be > > returned > > When pyparted was written, python 1.5.2 was young. This was before > iterators. I'd be happy to see someone implement list access through > iterators in pyparted, while keeping the _next interfaces for backward > compatibility. Ok. I'll implement those iterators in pylibparted. :-) Best regards, -- Ulisses
