On Tue, 2008-05-13 at 10:04 +0200, Joel Andres Granados wrote: > I agree with you. What I propose is not a change to the old API but an change to the new one before it gets out the door. We can have a function that has an argument "validonly" (or something like that) which is false by default. This would mean that the call will have the argument only when the caller wants to ensure a valid "next partition". In other words: > > nextvalidpartition = next_partition(validonly=true) > nextpartition = next_partition() > > my point being that the check for the validity of the partition, IMO, is better > put inside pyparted and not in a higher level. This does not change the semantics > of the current calls. the next_partition() will still work and will still return > the next partition, valid or invalid. So stuff that uses that function will not > be invalid after the change. It does change the semantics of the calls where we > want to ensure that the next partition is valid, it additionally does away with > the couple of lines that check for the validity. For the new API, we should just get rid of the next_partition() stuff altogether and do something iterator based -- for p in disk.partitions would be oh so nice :) And at that point, we could make that just return active partitions[1], leaving the special cases to use a special case API. But, veering off the course now Jeremy [1] In fact, maybe it makes sense that it only returns active, non-freespace partitions that are in use. Maybe not extendeds either. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
