[Python-Dev] address manipulation in the standard lib
Guido van Rossum
guido at python.org
Mon Jan 5 18:44:12 CET 2009
On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor
<duncan.mcgreggor at gmail.com> wrote:
> Last Fall, Guido opened a ticket to include Google's ipaddr.py in the
> standard lib:
> There has been some recent discussion on that ticket, enough so that
> it might benefit everyone if it was moved on to the dev list. I do
> recommend reading that ticket, though -- lots of good perspectives are
> The two libraries that are being discussed the most for possible
> inclusion are the following:
> * http://code.google.com/p/ipaddr-py/wiki/IPAddrExmples
> * http://code.google.com/p/netaddr/wiki/NetAddrExamples
> The most immediately obvious differences between the two are:
> * ipaddr supports subnet/supernet/net exclusions
> * netaddr supports EUI/MAC address manipulations
> * the netaddr API differentiates between an IP and a CIDR block
> * netaddr supports wildcard notation
> * netaddr supports binary representations of addresses
> * ipaddr is one module whereas netaddr consists of several (as well
> as IANA data for such things as vendor lookups on MAC addresses)
> * ipaddr benchmarks as faster than netaddr
> * netaddr is currently PEP-8 compliant
> That's a quick proto-assessment based on looking at examples and unit
> tests and didn't include a thorough evaluation of the code itself.
Thanks for the summary! I've been on vacation and unable to follow the
details. Note that I have no vested interest in Google's module except
knowing it has many happy users (I have never used it myself).
> Martin provided some very nice guidelines in a comment on the ticket:
> "I think Guido's original message summarizes [what we need]: a module
> that fills a gap for address manipulations... In addition, it should
> have all the organisational qualities (happy user base, determined
> maintainers, copyright forms, documentation, tests). As to what
> precisely its API should be - that is for the experts (i.e. you) to
> determine. I personally think performance is important, in addition to
> a well-designed, useful API. Conformance to PEP 8 is also desirable."
> I'm planning to chat with both David Moss (netaddr) and Peter Moody
> (ipaddr) on the mail lists about API details, and I encourage others
> to do this as well. As for this list, it's probably important to
> define the limits of the desired feature set for an ip address
> manipulation library:
> * do we want to limit it to IP (i.e. no EUI/MAC support)?
I don't want to exclude EUI/MAC support, but it seems quit a separate
(and much more specialized) application area, so it's probably best to
keep it separate (even if it may make sense to use a common (abstract
or concrete) base class or just have similar APIs).
> * do we want a single module or is a package acceptable?
I don't care either way.
> * what features would folks consider essential or highly desirable
> (details on this will be discussed on the project mail lists)
> * other thoughts?
How about a merger?
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev