Good evening fellow Pythonistas,
Considering a PEP is now available I'd like to join this discussion and raise several points with regard to both the PEP and the ipaddr reference implementation put forward with it.
1) Firstly, an offering of code.
I'd like to bring to your attention an example implementation of an IP address library and interface for general discussion to compare and contrast with ipaddr 2.0.x :-
http://netaddr.googlecode.com/svn/branches/exp_0.7.x_ip_only
It is based on netaddr 0.7.2 which I threw together earlier today.
In essence, I've stripped out all of what could be considered non-essential code for a purely IP related library. This branch should be suitable for *theoretical* consideration of inclusion into some future version of the Python standard library (with a little work).
It is a pure subset of netaddr release 0.7.2, *minus* the following :-
- all IEEE layer-2 code
- some fairly non-essential IANA IP data files and lookup code
- IP globbing code (fairly niche)
Aside: Just a small mention here that I listened carefully to Clay McClure's and others criticisms of the previous incarnation of ipaddr. The 0.7.x series of netaddr breaks backward compatibility with previous netaddr releases and is an "answer" of sorts to that discussion and issue raised within the Python community. I hope you like what I've done with it.
For the purposes of this discussion consider this branch the "Firefox to netaddr's Mozilla" or maybe just plain old "netaddr-ip-lite" ;-)
2) I refute bold claim in the PEP that :-
"Finding a good library for performing those tasks can be somewhat more difficult."
On the contrary, I wager that netaddr is now a perfectly decent alternative implementation to ipaddr, containing quite a few more features with little of the slowness for most common operations, 2/3x faster in a lot of cases, not that we're counting. What a difference a year makes! I also rate IPy quite highly even if it is getting a little "long in the tooth". For a lot of users, IPy could also be considered a nice, stable API!
By the same token I'm happy to note some convergence between the ipaddr and netaddr's various interfaces, particularly in light of discussions and arguments put forward by Clay McClure and others. A satisfactory compromise between the two however still seems a way off.
3) I also disagree with the PEP's claim that :-
"attempts to combine [IPv4 and IPv6] into one object would be like trying to force a round peg into a square hole (or vice versa)".
netaddr (and for that matter IPy) cope with this perceived problem admirably.
netaddr employs a simple variant of the GoF Strategy design pattern (with added Python sensibility). In the rare cases where ambiguity exists between IPv4 and IPv6 addresses a version parameter may be passed to the constructor of the IPAddress class to differentiate between them. Providing an IP address version to the constructor also provides a small performance improvement.
IPv4 and IPv6 addresses can be used interchangably throughout netaddr without causing issue during operations such as sorting, merging (known in the PEP as "address collapsing") or address exclusion.
Don't try and do this with the current reference implementation of ipaddr :-
>>> collapse_address_list([IPv4Address('1.1.1.1'), IPv6Address('::1.1.1.1')])
[IPv4Network('1.1.1.1/32')]
OUCH! Even if this isn't allowed (according to the documentation), it should raise an Exception rather than silently passing through.
I actually raised this back in May on the ipaddr bug tracker but it hasn't received any attention so far :-
http://code.google.com/p/ipaddr-py/issues/detail?id=18
Compare this with netaddr's behaviour :-
>>> cidr_merge([IPAddress('1.1.1.1'), IPAddress('::1.1.1.1')])
[IPNetwork('1.1.1.1/32'), IPNetwork('::1.1.1.1/128')]
That's more like it.
4) It may just be me but the design of this latest incarnation of ipaddr seems somewhat complicated for so few lines of code. Compared with ipaddr, netaddr doesn't use or require multiple inheritance nor a seemingly convoluted inheritance heirarchy. There isn't a need for an IP() type 'multiplexer' function either (although I might be missing an important use case here). But, then again, this may just be my personal preference talking here. I prefer composition over inheritance in most cases.
In netaddr, if a user wants to represent an IP address (without netmask), they should use the IPAddress class, if they want to represent and IP address with some form of mask, they should use the IPNetwork class.
5) The ipaddr library is also missing options for expanding various (exceedingly common) IP abbreviations.
>>> from netaddr import IPNetwork
>>> IPNetwork('10/8', True)
IPNetwork('10.0.0.0/8')
netaddr also handles classful IP address logic, still pervasive throughout modern IP stacks :-
>>> IPNetwork('192.168.0.1', True)
IPNetwork('192.168.0.1/24')
Note that these options are disabled by default, to keep up the speed of the IPNetwork constructor up for more normal cases.
6) netaddr currently contains a lot of useful features absent in ipaddr that would be extremely useful in a general, "lightweight" IP library.
For example, it already contains routines for :-
- arbitrary address range calculations
- full assistance for IPv4-mapped/compatible IPv6 addressing
- a fully function IPSet class which allows you to perform operations such as unions, intersections and symmetric differences between lists of IPNetwork (CIDR) objects.
The last one is actually really handy and is based on an idea for an IPv4 only library by Heiko Wundram posted to the ASPN Python Cookbook some years ago (details can be found in the netaddr THANKS file).
There is a lot more to consider here than I can cram into this initial message, so I'll hand over to you all for some (hopefully) serious debate.
Regards,
David P. D. Moss
netaddr author and maintainer
PS - Why does the References section in the PEP contain links to patches already applied to the ipaddr 2.0.x reference implementation?