Jeremy Katz wrote:
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.
The iterator idea is a very good one!!!! Something to think about before releasing the new pyparted bits.
Going to patch up anaconda for now and see if I can come up with something for the iterator thing. Haven't played with iterator and python bindings so don't really know how complex the whole thin is. But its worth a look.
--
Joel Andres Granados
Red Hat / Brno, Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list