[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,
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