On Fri, Jul 22, 2005 at 07:09:10PM -0300, Ulisses Furquim wrote: > > Hmm.. I don't think they are much the same. Right now I see the > following differences between pyparted and pylibparted: > > - 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. > - pylibparted uses methods to access objects' data I'm not convinced that it's a big win for libpyparted. It's more typing... > - pylibparted has more of libparted's functions implemented True - I never had a need to implement timers. > - 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. > - 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. > - 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. Cheers, Matt -- Matt Wilson rpath, Inc. msw@xxxxxxxxx
