On Tue, Aug 30, 2011 at 10:00 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Aug 28, 2011 at 7:53 PM, Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia