[Python-Dev] address manipulation in the standard lib

[Duncan McGreggor]

On Mon, Jan 5, 2009 at 11:44 AM, Guido van Rossum <guido at python.org> wrote:
> 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:
>>  http://bugs.python.org/issue3959
>>
>> 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
>> represented.
>>
>> 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?

I think that's a brilliant idea. David and Peter, logistics aside,
what do you think of (or how to you feel about) this suggestion?

Or, if not a complete merger, unifying everything that is desired in
the standard library. The code not included (e.g. EUI/MAC address
stuff, vendor lookups, etc.) could continue its existence as a
project, using the stdlib as a basis...

d