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.
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.
1) Additional is_<network_class> boolean properties.
IPv6Address.is_ipv4_compat
IPv6Network.is_ipv4_compat
Returns True if this address/network is IPv4-compatible IPv6 e.g.
::192.0.2.0 or ::192.0.2.0/124, False otherwise.
IPv6Address.is_ipv4_mapped
IPv6Network.is_ipv4_mapped
Returns True if this address/network is IPv4-compatible IPv6 e.g.
::ffff:192.0.2.0 or ::ffff:192.0.2.0/124, False otherwise.
IPvXAddress.is_reserved
IPvXNetwork.is_reserved
Possible list of IPv4 networks and ranges to be used for this purpose :-
# IANA Reserved but subject to allocation
39.0.0.0/8
128.0.0.0/16
191.255.0.0/16
192.0.0.0/24
223.255.255.0/24
# Reserved for Future Use
240.0.0.0/4
# Reserved multicast
234.0.0.0 - 238.255.255.255
225.0.0.0 - 231.255.255.255
Possible list of IPv6 networks to be used for this purpose :-
FF00::/12
::/8
0100::/8
0200::/7
0400::/6
0800::/5
1000::/4
4000::/3
6000::/3
8000::/3
A000::/3
C000::/3
E000::/4
F000::/5
F800::/6
FE00::/9
IPvXAddress.is_unicast
IPvXNetwork.is_unicast
True if addresses or networks are within unicast ranges.
2) An IPvXRange class (representing an arbitrary start and end IP address).
This is in addition to the existing summarize_address_range() function.
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.
3) Support for IPv4-mapped/compatible IPv6 conversion functions.
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.
Basic examples :-
IPv4 -> IPv6
>>> IPv6Address('::ffff:192.0.2.0').ipv4()
IPv4Address('192.0.2.0')
>>> IPv6Address('::192.0.2.0').ipv4()
IPv4Address('192.0.2.0')
IPv4 -> IPv6
>>> IPv4Address('192.0.2.0').ipv6()
IPv6Address(::ffff:192.0.2.0') Prefer IPv4-compatible as the default (RFC
4291)
>>> IPv4Address('192.0.2.0').ipv6(ipv4_mapped=True)
IPv6Address('::192.0.2.0')
By the same token we should provide the same functionality for IP network
classes (with the necessary CIDR prefix conversions) :-
>>> IPv6Network('::ffff:192.0.2.0/120').ipv4()
IPv4Network('192.0.2.0/24')
>>> IPv4Network('192.0.2.0/24').ipv6()
IPv6Network('::ffff:192.0.2.0/120')
>>> IPv4Network('192.0.2.0/24').ipv6(ipv4_mapped=True)
IPv6Network('::192.0.2.0/120')
If address ranges overflow boundaries the necessary exceptions can be
thrown.
4) IP set based classes.
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.
That's all for now,
Dave M.
2009/8/27 Peter Moody <pe...@hda3.com>
> On Thu, Aug 27, 2009 at 10:37 AM, Peter Moody<pe...@hda3.com> wrote:
> > On Thu, Aug 27, 2009 at 10:24 AM, David Moss<drk...@gmail.com> wrote:
> >> Peter,
> >>
> >> I would like to apologise if I have caused you any offense.
> >
> > Thanks. Accepted.
> >
> >> Please can we
> >> put the animosity behind us and stick to pulling together the best IP
> >> library possible as part of this PEP?
> >
> > pep-3144 should hopefully soon be updated on python.org/dev/peps with
> > this past week's suggestions (including a discussion on the ipaddr
> > class design). The updated ipaddr reference code should also still be
> > available for 'svn co' at
> > https://ipaddr-py.googlecode.com/svn/branches/2.0.x
>
> er, make that http://ipaddr-py.googlecode.com/svn/branches/2.0.x
>
> https seems to ask for a password.
>
> > Cheers,
> > /peter
> >
> >> Regards,
> >>
> >> Dave M.
> >>
> >
>
_______________________________________________
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
