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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4