[Python-Dev] Issues with Py3.1's new ipaddr

[Clay McClure]

On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" <martin at 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