On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor <duncan.mcgreg...@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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
