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

[Clay McClure]

On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

>> If this were a core feature that many developers were anxiously
>> awaiting, I could understand the desire to release and iterate. But is
>> there really a pressing need for an IP library in the stdlib?
>
> You should have asked this question a few month ago. Now, release
> mechanics make it difficult to remove the library, except if a severe
> problem was uncovered - which you haven't been able to demonstrate.

This argument makes no sense. The feasibility of removing the library
does not depend on the severity of the issues found within it. Either
it is hard to remove the library, or it is easy. If it's hard to
remove, it doesn't get any easier because I discover a fatal flaw.

I've actually provided several examples of where the library fails
when used in common scenarios, yet your solution involves incremental
hacks that don't fix the underlying problems. You write as if you have
a vested interest in releasing the library -- why?

> I don't believe that your issue "hosts and nets are represented with the
> same class" is severe: it is very well possible to use the IP function
> to represent individual hosts (including having a string representation
> that doesn't print a netmask). The only possibly-missing feature is
> support for rejecting host strings that include a mask on parsing; that
> can be added in a backwards-compatible way as an optional parameter to
> the IP function (as discussed on the tracker).

There are other missing features, but again, my concern is not about
missing features: it's about a quirky API that conflates concepts in
the problem domain, leading to subtle bugs and breaking the principle
of least surprise.

Clay