[Python-ideas] IP addressing library, aka reviving PEP 3144 (Re: Add from __experimental__ import bla)

[Nick Coghlan]

On Tue, Aug 30, 2011 at 10:00 AM, Guido van Rossum <guido at python.org> wrote:
> On Sun, Aug 28, 2011 at 7:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> [Lots of stuff I agree with, and then]
>
>> Here's another potentially useful litmus test question for Guido: if
>> it was spelled "from __experimental__ import ipaddr", would you be
>> more inclined to approve PEP 3144 (IP address library) for 3.3?
>
> IIRC the issue with that PEP is that there is a stand-off between two
> authors of competing implementations, and I don't have enough
> understanding of the issues to be able to tell who's right. (Or maybe
> they're both right and they're just aiming at different audiences --
> but I can't even tell that.)

In reviewing the situation, that was actually the objection to the 3.1
incarnation of the ipaddr module (which was in SVN for a while before
being reverted). Several changes were made to ipaddr before it was
proposed for inclusion in 3.2 that largely resolved those objections
(primarily, the 2.x series of ipaddr-py makes a much stronger
distinction between networks and hosts:
http://mail.python.org/pipermail/python-dev/2009-September/092384.html)

The netaddr folks have a nice page (albeit a couple of years old now)
listing some of the many incarnations of this particular wheel, so
it's clearly base functionality worth providing as an included
battery:
https://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule

> I think we need to have someone who cares more (but is not either of
> those authors) to review the PEP and its criticism and decide on a way
> forward.
>
> (Or am I being too soft? If nobody cares I'd be happy to toss a coin.)

This request inspired me to go back and look at those old discussions.
This comment from Scott Dial seems to summarise the core of the
concern with the PEP 3144 version of the ipaddr API:
http://mail.python.org/pipermail/python-dev/2009-September/091713.html
RDM elaborated further here:
http://mail.python.org/pipermail/python-dev/2009-September/092262.html

It also turns out ipaddr is completely lacking in explicit prose
documentation, so it would at least need that before it could be
included. Such documentation would also be a useful adjunct to the
PEP, since it would focus on what the module is like to *use* rather
than how it is built.

As near as I can tell, the core objection (the fact that IP network
objects aren't normalised on creation, making their behaviour
thoroughly surprising to anyone that actually understands the
differences between IP addresses, IP networks, IP interfaces and IP
hosts) remains valid, so I withdraw my suggestion that the current API
should be added even as experimental code. I had forgotten about the
identified problems with ipaddr until rereading the old thread
reminded me of them.

I believe the PEP would be significantly more palatable with the
following changes/additions:
1. Draft ReStructuredText documentation for inclusion in the stdlib docs
2. Removal of the "ip" attribute of IP network objects (since it makes
the nominal "networks" behave like IP interface definitions)
3. "network" property renamed to "netaddr" (since it returns an
address object rather than a network object)
4. "strict" parameter removed from class signatures, replaced with
class method for non-strict behaviour
5. Factory functions renamed so they don't look like class names
(ip_network, ip_address, ip)
6. "strict" parameter on factory functions modified to default to True
rather than False
7. Addition of an explicit "IPInterface" class to cover the
association of an address with a specific network that is currently
handled by storing arbitrary addresses on IP network objects

IIRC, this is basically the point we reached last time, but Peter
either wasn't interested in contributing/maintaining the module on
those terms or else got sidetracked by other things. If he's no longer
interested in contributing the module or not willing to implement any
changes to address the concerns, it would be good to have an explicit
statement to that effect, then we can mark the PEP as rejected and
leave the field open to other proposals.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia