I've posted several of issues to the ipaddr bug tracker for consideration. They shouldn't be major discussion topics so I'll leave them off the list.<br><br>The following are a few feature requests that might possibly require further discussion here. If they are no-brainers that don't require any further mulling over, can we have a few votes -1/+1 to get a feel for the importance and I'llI convert them into tickets.<br>
<br>1) Additional is_<network_class> boolean properties.<br><br>IPv6Address.is_ipv4_compat <br>IPv6Network.is_ipv4_compat <br>
<br>Returns True if this address/network is IPv4-compatible IPv6 e.g. ::192.0.2.0 or ::<a href="http://192.0.2.0/124">192.0.2.0/124</a>, False otherwise.<br><br>IPv6Address.is_ipv4_mapped<br>IPv6Network.is_ipv4_mapped<br>
<br>Returns True if this address/network is IPv4-compatible IPv6 e.g. ::ffff:192.0.2.0 or ::ffff:<a href="http://192.0.2.0/124">192.0.2.0/124</a>, False otherwise.<br>
<br>IPvXAddress.is_reserved<br>
IPvXNetwork.is_reserved<br><br>Possible list of IPv4 networks and ranges to be used for this purpose :-<br><br># IANA Reserved but subject to allocation<br><a href="http://39.0.0.0/8">39.0.0.0/8</a><br><a href="http://128.0.0.0/16">128.0.0.0/16</a><br>
<a href="http://191.255.0.0/16">191.255.0.0/16</a><br><a href="http://192.0.0.0/24">192.0.0.0/24</a><br><a href="http://223.255.255.0/24">223.255.255.0/24</a><br><br># Reserved for Future Use<br><a href="http://240.0.0.0/4">240.0.0.0/4</a> <br>
<br># Reserved multicast<br>234.0.0.0 - 238.255.255.255<br>225.0.0.0 - 231.255.255.255<br><br>Possible list of IPv6 networks to be used for this purpose :-<br><br>FF00::/12<br>::/8<br>0100::/8<br>0200::/7<br>0400::/6<br>
0800::/5<br>1000::/4<br>4000::/3<br>6000::/3<br>8000::/3<br>A000::/3<br>C000::/3<br>E000::/4<br>F000::/5<br>F800::/6<br>FE00::/9<br> <br>IPvXAddress.is_unicast <br>IPvXNetwork.is_unicast<br><br>True if addresses or networks are within unicast ranges.<br>
<br>2) An IPvXRange class (representing an
arbitrary start and end IP address). This is in addition to the
existing summarize_address_range() function.<br><br>There are use cases were an actual object representing an arbitrary range rather than a basic tuple containing two IPvXAddress objects or a list of IPvXNetwork objects is just simple to handle, more appropriate and less hassle overall. Willing to expand on the interface for this.<br>
<br>3) Support for IPv4-mapped/compatible IPv6 conversion functions.<br><br>It would be handy to have methods to convert backwards and forwards between actual IPv4 addresses and networks to their IPv6 mapped or compatible counterparts.<br>
<br>Basic examples :-<br><br>IPv4 -> IPv6<br><br>>>> IPv6Address('::ffff:192.0.2.0').ipv4()<br>IPv4Address('192.0.2.0')<br><br>>>> IPv6Address('::192.0.2.0').ipv4()<br>
IPv4Address('192.0.2.0')<br>
<br>IPv4 -> IPv6<br><br>>>> IPv4Address('192.0.2.0').ipv6()<br>
IPv6Address(::ffff:192.0.2.0') Prefer IPv4-compatible as the default (RFC 4291)<br>
<br>>>> IPv4Address('192.0.2.0').ipv6(ipv4_mapped=True)<br>
IPv6Address('::192.0.2.0')<br>
<br>By the same token we should provide the same functionality for IP network classes (with the necessary CIDR prefix conversions) :-<br><br>>>> IPv6Network('::ffff:<a href="http://192.0.2.0/120').ipv4(">192.0.2.0/120').ipv4(</a>)<br>
IPv4Network('<a href="http://192.0.2.0/24">192.0.2.0/24</a>')<br>
<br>>>> IPv4Network('<a href="http://192.0.2.0/24').ipv6(">192.0.2.0/24').ipv6(</a>)<br>IPv6Network('::ffff:<a href="http://192.0.2.0/120">192.0.2.0/120</a>')<br>
<br>
>>> IPv4Network('<a href="http://192.0.2.0/24').ipv6(ipv4_mapped=True">192.0.2.0/24').ipv6(ipv4_mapped=True</a>)<br>
IPv6Network('::<a href="http://192.0.2.0/120">192.0.2.0/120</a>')<br><br>If address ranges overflow boundaries the necessary exceptions can be thrown.<br><br>4) IP set based classes.<br><br>This is a big topic, so I'll save it for a subsequent post. What are the general feelings about having something like this in ipaddr? It might be deemed a little heavyweight but it is a really sweet option for the power user. Combined with the new speed of collapse_address_list() this could be handy and fast. <br>
<br>That's all for now,<br><br>Dave M.<br><br><div class="gmail_quote">2009/8/27 Peter Moody <span dir="ltr"><<a href="mailto:peter@hda3.com">peter@hda3.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Thu, Aug 27, 2009 at 10:37 AM, Peter Moody<<a href="mailto:peter@hda3.com">peter@hda3.com</a>> wrote:<br>
> On Thu, Aug 27, 2009 at 10:24 AM, David Moss<<a href="mailto:drkjam@gmail.com">drkjam@gmail.com</a>> wrote:<br>
>> Peter,<br>
>><br>
>> I would like to apologise if I have caused you any offense.<br>
><br>
> Thanks. Accepted.<br>
><br>
>> Please can we<br>
>> put the animosity behind us and stick to pulling together the best IP<br>
>> library possible as part of this PEP?<br>
><br>
> pep-3144 should hopefully soon be updated on <a href="http://python.org/dev/peps" target="_blank">python.org/dev/peps</a> with<br>
> this past week's suggestions (including a discussion on the ipaddr<br>
> class design). The updated ipaddr reference code should also still be<br>
> available for 'svn co' at<br>
> <a href="https://ipaddr-py.googlecode.com/svn/branches/2.0.x" target="_blank">https://ipaddr-py.googlecode.com/svn/branches/2.0.x</a><br>
<br>
</div></div>er, make that <a href="http://ipaddr-py.googlecode.com/svn/branches/2.0.x" target="_blank">http://ipaddr-py.googlecode.com/svn/branches/2.0.x</a><br>
<br>
https seems to ask for a password.<br>
<div><div></div><div class="h5"><br>
> Cheers,<br>
> /peter<br>
><br>
>> Regards,<br>
>><br>
>> Dave M.<br>
>><br>
><br>
</div></div></blockquote></div><br>