On Mon, Jan 30, 2012 at 1:44 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Tue, Jan 31, 2012 at 4:19 AM, Scott Dial > <scott+python-...@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 <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038 _______________________________________________ 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
