On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed.
How long do release candidates soak in the field before being accepted? I'm curious if an exception could be made in this case, given that you have admitted that ipaddr is not an important library. The chances of a problem being introduced due to its removal are vanishingly small. No other components of the stdlib depend on ipaddr, and the few (approximately zero?) developers who will have started writing applications depending on ipaddr due to its inclusion in the release candidate could simply download the library from Google.
I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason).
I believe the API is quirky because: * It tries to represent distinct domain model concepts in a single class * Its methods and properties are strangely named * Methods and properties that should return domain model objects return native types instead * It cannot correctly parse output from netstat, nor can it correctly pass values to ifconfig You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. If you consult the issue notes, you'll see objections of the type I just mentioned were raised months ago, yet no work has been done to correct them. The only changes that I can see were related to pedantic style issues: camel case and indentation. Clay