[Python-Dev] PEP 3144 ipaddr module (was Re: PEP 408 -- Standard library preview package) (original) (raw)

Peter Moody pmoody at google.com
Mon Jan 30 22:52:26 CET 2012

On Mon, Jan 30, 2012 at 1:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Tue, Jan 31, 2012 at 4:19 AM, Scott Dial <scott+python-dev at scottdial.com> wrote:

PEP 3144 wasn't pronounced upon because there were significant disagreements about the design of the API proposed in the PEP. As it stands, I believe the authorship of ipaddr either decided that they were not going to compromise their module or lost interest.

See Nick Coghlan's summary: http://mail.python.org/pipermail//python-ideas/2011-August/011305.html Peter Moody actually addressed all my comments from last year (alas, I forgot that python-ideas got dropped from the latter part of the email chain, so it became a private discussion between Peter, Guido and myself). I apparently got distracted by other issues and never followed up on Peter's final review request. The branch with the relevant changes is here (these weren't added back into ipaddr mainline since they aren't all backwards compatible with the existing ipaddr API): http://code.google.com/p/ipaddr-py/source/browse/#svn%2Fbranches%2F3144 Peter was very responsive and accommodating during that discussion :) (The notes below are an edited version of Peter's off-list reply to me from last year, reflecting the final state of the ipaddr 3144 branch) On Mon, Aug 29, 2011 at 7:09 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:  I believe the PEP would be significantly more palatable with the  following changes/additions:  1. Draft ReStructuredText documentation for inclusion in the stdlib docs (still needed)  2. Removal of the "ip" attribute of IP network objects (since it makes  the nominal "networks" behave like IP interface definitions) the Class hierarchy now looks like: IPAddrBase(object) # mother of everything BaseAddress(IPAddrBase) # base for addresses BaseNetwork(IPAddrBase) # base for networks and interfaces, could use be renamed. BaseV4(object) # ipv4 base BaseV6(object) # ipv6 base IPv4Address(BaseV4, BaseAddress) IPv4Interface(BaseV4, BaseNetwork) IPv4Network(IPv4Interface) IPv6Address(BaseV6, BaseAddress) IPv6Interface(BaseV6, BaseNetwork) IPv6Network(IPv6Interface) (essentially, the current ipaddr "Network" objects become "Interface" objects in PEP 3144, with a new strict "Network" object that has no ip attribute)  3. "network" property renamed to "netaddr" (since it returns an  address object rather than a network object) renamed to networkaddress. did the same for the broadcastaddress.  4. "strict" parameter removed from class signatures, replaced with  class method for non-strict behaviour 'strict' is gone, just create IPv*Interface objects or use the ipinterface API instead. Network objects are always strict.  5. Factory functions renamed so they don't look like class names  (ipnetwork, ipaddress, ip) Now ipaddress, ipnetwork, ipinterface  6. "strict" parameter on factory functions modified to default to True  rather than False 'strict' is gone. Interfaces allow a host IP, Networks don't.  7. Addition of an explicit "IPInterface" class to cover the  association of an address with a specific network that is currently  handled by storing arbitrary addresses on IP network objects done. So with a cleanup of the docstrings (and creation of some ReST docs based on them) a definite +1 from me for inclusion of ipaddr (based on the 3144 branch in SVN) in 3.3. (with the tweaks to the API, we may want to use a different name like "ipaddress" or "iptools", though - otherwise people could be legitimately confused by the differences relative to the PyPI "ipaddr" module)

Cleaning up the docstrings and re-tooling the PEP was where I stalled after addressing your comments. Easy enough to complete if there's still interest.

Note, http://pypi.python.org/pypi/ipaddr is actually the same module, but down a few versions. I'm not sure if your concern is about the same library having such a different api or if you had thought they were completely different libraries.

Cheers, peter

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

-- Peter Moody      Google    1.650.253.7306 Security Engineer  pgp:0xC3410038

More information about the Python-Dev mailing list