[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [patch] this is a pyparted patch for 429185
- From: Jeremy Katz <katzj redhat com>
- To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-list redhat com>
- Subject: Re: [patch] this is a pyparted patch for 429185
- Date: Tue, 13 May 2008 06:54:49 -0400
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.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]