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

[Gregory P. Smith]

On Tue, Jun 2, 2009 at 1:11 PM, Jake McGuire <mcguire at google.com> wrote:
> The minimal demonstration of the problem of representing networks and
> addresses using the same class:

fwiw, that (hosts vs networks in the same class) is not what you are
demonstrating below.  What you demonstrate is that its silly for
iteration over a network to return strings rather than IP objects.
Regardless, it is a good example of a problem with the API.

ipaddr could be changed to yield IPv4 /32 or IPv6 /128 objects when
iterating over it instead of strings and this example would work
properly.

>>>> container = [1, 2, 3, 4]
>>>> for item in container:
> ...   print "%s in %s: %s" % (item, container, item in container)
> ...
> 1 in [1, 2, 3, 4]: True
> 2 in [1, 2, 3, 4]: True
> 3 in [1, 2, 3, 4]: True
> 4 in [1, 2, 3, 4]: True
>>>> import ipaddr
>>>> container = ipaddr.IP('192.168.1.0/24')
>>>> for item in container:
> ...   print "%s in %s: %s" % (item, container, item in container)
> ...
> Traceback (most recent call last):
>  File "<stdin>", line 2, in <module>
>  File "ipaddr.py", line 438, in __contains__
>    return self.network <= other.ip and self.broadcast >= other.broadcast
> AttributeError: 'str' object has no attribute 'ip'
>>>>

Regardless, after reading the many different opinions on this thread
especially including those of other python developers it sounds like
we should not include ipaddr in 3.1.

This example is IMHO one good reason to not include ipaddr in the
standard library as it stands.

It sounds like we have a 3.1rc2 scheduled for June 13th.  At this
point based on the multitude of other developer comments in these
threads and barring strong arguments in favor of including it as it
stands I will remove it because there seem to be quite a number of
people with objections to it as an API in its current form.

I've filed http://bugs.python.org/issue6182 as a release blocker to
track its removal (or not) based on any further discussion in these
python-dev threads.

I do believe an API for an ip and network address manipulation library
can be worked out but during the 3.1 release candidate phase is not
the time to hastily do that and choose one so removal due to
disagreement seems the best option.

Would someone volunteer write up a proposal (PEP) for such with a goal
of having it completed within the next few months?  (I know people
have suggested various other libraries, that counts; i have not taken
the time to look at them).

-gps