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

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 network_address.
> did the same for the broadcast_address.
>    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
> ip_interface API instead. Network objects are always strict.
>    5. Factory functions renamed so they don't look like class names
>    (ip_network, ip_address, ip)
> Now ip_address, ip_network, ip_interface
>    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,
> 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