google / ipaddr-py Goto Github PK

What steps will reproduce the problem?
1. examine the unittests
2. the IPv6 string literals are all upper case
3. observe that inet_pton() everywhere standardized (long ago) on lower case

What is the expected output? What do you see instead?

IPv6 string literals should be lower case.

What version of the product are you using? On what operating system?

svn checkout at r6.

Please provide any additional information below.

Patch available at http://codereview.appspot.com/7678

What steps will reproduce the problem?
>>> import ipaddr
>>> ipaddr.IPv4Address('1.1.1.1').version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "ipaddr.py", line 434, in version
    raise NotImplementedError('BaseIP has no version')
NotImplementedError: BaseIP has no version
>>> ipaddr.IPv4Address('1.1.1.1')._version
4
>>>

Changing class declaration from:

class IPv4Address(BaseIP, BaseV4):

to

class IPv4Address(BaseV4, BaseIP):

Fixes the problem and seems to be in line with how IPv6Address is declared.

Currently the IPvXNetwork class exposes the following properties :-

is_link_local
is_loopback
is_multicast
is_private

It would be great to have these exposed for individual IPvXAddress objects
as well. In the case of is_multicast this is especially important.

What version of the product are you using?

ipaddr 2.0.x r97

What steps will reproduce the problem?

$ python ipaddr_test.py 
........................................
----------------------------------------------------------------------
Ran 40 tests in 0.027s

OK

$ svn st
?      ipaddr.pyc




What is the expected output? What do you see instead?

Expected output - none
Actual output - ?     ipaddr.pyc


What version of the product are you using? On what operating system?

Revision: 5

Please provide any additional information below.

svn propset ’svn:ignore’ ‘*.pyc’ .

What steps will reproduce the problem?
1. install python 3.1.1 
2. svn checkout http://ipaddr-py.googlecode.com/svn/trunk/ ipaddr-py-read-only
3. python3.1 setup.py install
4. on python3.1.1 cli
>>> from ipaddr import *
>>> IPv4Address('12.2.2.2')

What is the expected output? What do you see instead?
I get:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python3.1.1/lib/python3.1/site-packages/ipaddr.py", line 1169,
in __init__
    if isinstance(address, (int, long)):


What version of the product are you using? On what operating system?
Svn rev 124/ubuntu 904/x86_64

Please provide any additional information below.
Bug applies to the 2.0.0 snapshot too.

What steps will reproduce the problem?

In IPy:

In [2]: IP('192.168.1.0/24').overlaps('192.168.1.64/26')
Out[2]: 1

In ipaddr:

In [2]: 
IPv4Network('192.168.1.0/24').overlaps(IPv4Network('192.168.1.64/26'))
Out[2]: False


What is the expected output? What do you see instead?

True

See attached patch with test.

Please provide any additional information below.

In iPv6Network.__init__ a double check is performed, here[1] the patch.

[1] http://codereview.appspot.com/130092

A few typo's in IPAddress() checks for validation errors. Patch at
http://codereview.appspot.com/115076 .

Class IPv6 do not have method IsLoopback and IsMulticast.

Attached patch against 1.0.0 add this method.

Based on the current consensus Networks that define the same .network and 
.netmask should test equal ==, and the repr and str representations should 
be the same and not contain the IP use to generate the Network

I have done up a patch http://codereview.appspot.com/124057 such that

>>> IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)

>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
True
>>> hash(x) == hash(y)
True

The ip you instantiated the Network with is still accessible though, so
>>> x.ip
IPv4Address('192.168.1.1')
>>> y.ip
IPv4Address('192.168.1.0')

despite what the wiki is saying (and the python doc), ipaddr has no
attribute IPv4.
Is there a replacement for that purpose ?

> What version of the product are you using? On what operating system?

svn r127

>>> import ipaddr
>>> addr = ipaddr.IPv4('1.1.1.1/255.255.255.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'IPv4'

What steps will reproduce the problem?
1. ipaddr.IPNetwork('1.1.1.1') <= ipaddr.IPNetwork('1.1.1.1')
False

2.
3.

What is the expected output? What do you see instead?

True

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. ipaddr.IPv4Address(ipaddr.IPv4Address("1.1.1.1"))
2.
3.

What is the expected output? 

IPv4Address('1.1.1.1')

What do you see instead?

<type 'exceptions.AttributeError'>: 'IPv4Address' object has no attribute 
'split'

Please use labels and text to provide additional information.

>>> x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
>>> x
IPv4Network('192.168.1.1/16')

Parser allow a non-CIDR mask without raising an exception.

What steps will reproduce the problem?

In [1]: from ipaddr import *

In [2]: ip = IPAddress('192.0.2.0')

In [3]: ip
Out[3]: IPv4Address('192.0.2.0')

In [4]: IPAddress(ip)
AttributeError: 'IPv4Address' object has no attribute 'split'

What is the expected output?

In [4]: IPAddress(ip)
IPv4Address('192.0.2.0')

What version of the product are you using?

ipaddr 2.0.x r97

Please provide any additional information below.

Does work for IPvXNetwork objects.

What steps will reproduce the problem?
1. >>> import ipaddr
2. >>> net = ipaddr.IPv6Network('1234:1234:1234::/48')
3. >>> net.subnet(16)

Please provide any additional information below.

For very high number of subnets this could be unacceptable for its high
memory usage or if you need to assign subnets in a counter-like manner.

i posted[1] a patch to Rietveld (but really i don't know how does it works)
with relative tests.


[1] http://codereview.appspot.com/132049

What steps will reproduce the problem?

1. Use ip_ext_full for valid addr without double ':', for ex.

   ipaddr.IPv6('2001:4c30:100:2:2d0:b7ff:fed3:9a').ip_ext_full

We get:
2001:4c30:100:2:2d0:b7ff:fed3:9a 
but IMVHO it should be:
2001:4c30:0100:0002:02d0:b7ff:fed3:009a 
- like result for addr 2001:658:22A:CAFE:200::1.

What version of the product are you using? On what operating system?

ipaddr-py from trunk, python2.5 on Ubuntu 8.04

Please provide any additional information below.

Fix is simple, small patch for _explode_shorthand_ip_string in attachement.

What steps will reproduce the problem?
1. addr = IPv4("172.31.255.128/255.255.255.240")
2. list(addr)[-1] != addr[-1]

What is the expected output? What do you see instead?

addr[-1] should give last element of list: '172.31.255.143', but 
gives '172.31.255.142' instead.

What version of the product are you using? On what operating system?
1.0.2 on Debian Linux (Lenny), Python 2.5

Please provide any additional information below.
Fantastic tool, thank you! This minor bug might be the cause of some other 
hard-to-track-down problems.

What steps will reproduce the problem?


1. C:\Python30>python.exe ipaddr_test.py
  File "ipaddr_test.py", line 88
    self.assertEqual(self.ipv4.netmask, 4294967040L)
                                                  ^
SyntaxError: invalid syntax

C:\Python30>

What version of the product are you using? On what operating system?

ActivePython 3.0.1.1 (ActiveState Software Inc.) based on
Python 3.0.1 (r301:69556, Feb 18 2009, 10:20:03) [MSC v.1500 32 bit 
(Intel)] on win32

Try and create an IPv6 address with '1234:axy::b' and you get

ValueError: invalid literal for int() with base 16: '0axy'

Patch to fix this and updated test at http://codereview.appspot.com/115077

What steps will reproduce the problem?

look at the test case patch in rietveld


Please provide any additional information below.

Here the patch with little test: http://codereview.appspot.com/136047/show

What steps will reproduce the problem?

In [1]: from ipaddr import IP

In [2]: IP('192.168.0.1')
Out[2]: IPv4('192.168.0.1/32')

In [3]: IP('::192.168.0.1')
Out[3]: IPv6('::1:c0a8/128') # incorrect byte order.

In [4]: IP('::ffff:192.168.0.1')
Out[4]: IPv6('::ffff:1:c0a8/128') # incorrect byte order.

In [5]: IP('192.168.0.1').ip
Out[5]: 3232235521L

In [6]: IP('::192.168.0.1').ip
Out[6]: 114856 # incorrect integer value.

What is the expected output?

...

In [3]: IP('::192.168.0.1')
Out[3]: IPv6('::c0a8:1/128')

In [4]: IP('::ffff:192.168.0.1')
Out[4]: IPv6('::ffff:c0a8:1/128')

In [5]: IP('192.168.0.1').ip
Out[5]: 3232235521L

In [6]: IP('::192.168.0.1').ip
Out[6]: 3232235521L

What version of the product are you using?

rev 39

On what operating system?

- Linux Intel x86 (little endian)
- Solaris SPARC (big endian)

It raises a "IPv6 address is too large" error if the ip_int argument is a 
string.

Here's how to reproduce it:

In [2]: ipaddr.IPv6Address(1)._string_from_ip_int('1')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/xxx/<ipython console> in <module>()

/xxx/ipaddr/ipaddr.pyc in _string_from_ip_int(self, ip_int)
   1446
   1447         if ip_int > self._ALL_ONES:
-> 1448             raise ValueError('IPv6 address is too large')
   1449
   1450         hex_str = '%032x' % ip_int

ValueError: IPv6 address is too large

What steps will reproduce the problem?
1. python setup.py --license

What is the expected output? What do you see instead?

Apache License 2.0

What steps will reproduce the problem?
In [1]: import ipaddr

In [2]: ip = ipaddr.IP("172.16.1.0/24")

In [3]: ip[1:-2]

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/Users/pnasrat/Development/ipaddr-py-read-only/<ipython console> in <module>()

/Users/pnasrat/Development/ipaddr-py-read-only/ipaddr.pyc in
__getitem__(self, n)
    196   def __getitem__(self, n):
    197     if n >= 0:
--> 198       if self.network + n > self.broadcast:
    199         raise IndexError
    200       return self._StrFromIpInt(self.network + n)

TypeError: unsupported operand type(s) for +: 'long' and 'slice'

What is the expected output? 

A lis of IPs in the range 172.16.1.1 to 172.16.1.254 - as in [x for x in
ip] with network/broadcast skipped

What do you see instead?

TypeError: unsupported operand type(s) for +: 'long' and 'slice'


What version of the product are you using? On what operating system?

svn HEAD (r39)

"easy_install http://ipaddr-py.googlecode.com/files/ipaddr-1.0.0.tar.gz"
works, which is good. The discovery could be better, though.

If you registered the project with http://pypi.python.org/pypi, it would
become trivial for anyone to depend on it in larger projects. Installation
of the latest version would be a simple "easy_install ipaddr", and I would
be able to drop a line like "eggs = ipaddr==1.0.0" in my zc.buildout
configuration.

IPAddress() helper function (and probably some others) have incorrect
references to exception names. This produces a number of annoying errors.
Please refer to the attached patch.

The problem appears on ipaddr-py 2.0.0

Your __repr__ is ok, but it would be even more convenient if it emitted
real python code. In this case, it seems like that would be easy to do:

now:
In [6]: a = ipaddr.IPv4('10.1.0.1')

In [7]: repr(a)
Out[7]: '<ipaddr.IPv4: 10.1.0.1/32>'

better:
In [7]: repr(a)
Out[7]: "IPv4('10.1.0.1/32')"

The python result is less ambiguous and easier to paste into an interactive
python console for some debugging. E.g. if I print the repr of a dict of
addresses->hostnames, it would be cool if I could paste that whole result
into another python file for testing.

What steps will reproduce the problem?
1. from ipaddr import *
2. ip = IP('172.16.1.254/0.0.255.0')

This is a valid ACL / Inverse / Wildcard mask used by Cisco... address.py fails 
to compute it and 
rejects the numeric.

What is the expected output? What do you see instead?
Expected ipaddr to interpret the data as: 255.255.0.255 (where 255 is a static 
value, and the 0 
octet rotates to all combinations in the ip.) The range would then be, 
172.16.1-255.254

What version of the product are you using? On what operating system?
ipaddr-0.6.3, MacOSX 10.5

Please provide any additional information below.
I tried following the math used to verify "is_hostmask" but it looked like 
there are several places 
to account for a netmask that has rotating digits in any of the 4 octets.

   >>> ipaddr.IPv4Network('10/8')
   IPv4Network('0.0.0.10/8')
   >>> ipaddr.IPv4Network('192.168/16')
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/src/py/ipaddr/ipaddr.py", line 1246, in __init__
       raise IPv4IpValidationError(addr[0])
   ipaddr.IPv4IpValidationError: '192.168' is not a valid IPv4 address

from Andrew McNamara

both should currently raise ip validation errors.

Some protocols and applications (for example DNS or joining multicast
groups via socket.setsockopt) need a binary representation of an IP
address. For IPv4 addresses, socket.inet_aton can be used. On some
platforms supporting IPv6, socket.inet_pton can be used for IPv4 and IPv6
addresses. However, this excludes platforms with  (not socket.has_ipv6 or
sys.platform == 'win32').
A property ("packed") should be defined for the IPv4 and IPv6 classes and
return a binary representation (bytes in Python3+, str otherwise).
Additionally, as soon as the code is ported to python3, calling
IP(bytes_instance) should yield an IP i so that i.packed == bytes_instance .

What is the expected output? What do you see instead?
When excluding a non-inclusive addr, the original address should be
returned (since non-inclusive addr is already excluded).  Currently an
exception is raised.

Please provide any additional information below.
AddressExclude method is incorrectly raising errors.
If you try to exclude 10.2.0.0/16 from 10.1.0.0/16, then the correct
answer is that 10.2.0.0/16 is already excluded, so the response should be
10.1.0.0/16. Likewise for exluding an IPv6 from an IPv4, the correct
response should be to just return the IPv4.

Raising an error seems unnecessary. 


Patch:
230c230
<     """Remove an address from a larger block.

---
>     """Remove an address from a larger block, if possible.
255,259d254
<     Raises:
<       IPTypeError: If self and other are of difffering address versions.
<       IPAddressExclusionError: There was some unknown error in the address
<         exclusion process.  This likely points to a bug elsewhere in this
code.
<       ValueError: If other is not completely contained by self.
262,263c257
<       raise IPTypeError("%s and %s aren't of the same version" % (
<           str(self), str(other)))

---
>       return [self]
266c260
<       raise ValueError('%s not contained in %s' % (str(other), str(self)))

---
>       return [self]

A feature request that also exposes a few possible bugs when bad or
unexpected data is passed in via arguments. 

It would be nice to have string based arguments auto-detected when
specified by the end user.

What steps will reproduce the problem?

In [1]: from netaddr import *

In [2]: summarize_address_range('192.0.2.0', '192.0.2.255')
IPTypeError: first and last must be IP addresses, not networks

In [3]: collapse_address_list(['192.0.2.0/28', '192.0.2.16/28'])
AttributeError: 'str' object has no attribute '_prefixlen'

What is the expected output?

In [1]: from netaddr import *

In [2]: summarize_address_range('192.0.2.0', '192.0.2.255')
Out[2]: [IPv4Network('192.0.2.0/24')]

In [3]: collapse_address_list(['192.0.2.0/28', '192.0.2.16/28'])
Out[3]: [IPv4Network('192.0.2.0/27')]

What version of the product are you using?

ipaddr 2.0.x r97

Please provide any additional information below.

Using the copy constructor functionality of IPvXAddress or IPvXNetwork
objects on arguments passed into functions and methods would make this an
easy one to implement effectively and shouldn't noticeably slow code execution.

With ipaddr 1.1.0:

>>> import ipaddr
>>> x = ipaddr.IP('10.1.3.0/24')
>>> y = ipaddr.IP('10.1.2.128/25')
>>> x < y
True
>>> x > y
True

Addresses and networks are distinct concepts, and should not be conflated.

For example, we see how Python handles the treatment of scalars and collections:

>>> 1 == (1,)
False

Yet ipaddr asserts equality between scalars and collections:

>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
True

This is a design problem and should be resolved.

For an example of why 192.168.1.1 != 192.168.1.1/32, look no further than 
ifconfig:

# ifconfig en0 192.168.1.1/32
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
       inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
       ...

# ifconfig en0 192.168.1.1
# ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
       inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
       ...

ipaddr.IPv6Address('::ffff:10.10.0.0')

Expected Output:
IPv6Address('::ffff:a0a:0')

Actual Output:
IPv6Address('3a3a:6666:6666:3a31:302e:3130:2e30:2e30')

In contrast, see:
ipaddr.IPv6Address('::ffff:10.10.10.0')
or
ipaddr.IPv6Address('::ffff:10.10.0.10')

10.10.[0-9].0 all seem broken.

What version of the product are you using? On what operating system?
SVN revision 125 on 2.6.2 on Ubuntu 9.04 Jaunty.

Running a sort across a list of randomly shuffled IPvXAddress and
IPvXNetwork objects should always yield a consistent result.

Currently the ordering of elements with the same base (network) address but
different CIDR prefix shifts for every run of the example code.

What steps will reproduce the problem?

from ipaddr import *
import random

subnet = IPNetwork('192.0.2.0/28')
networks = [subnet]
networks.extend(list(subnet))
networks.extend(subnet.subnet(1))
networks.extend(subnet.subnet(2))
networks.extend(subnet.subnet(3))

random.shuffle(networks)

for subnet in sorted(networks):
    print subnet

What is the expected output?

192.0.2.0/28
192.0.2.0/29
192.0.2.0/30
192.0.2.0/31
192.0.2.0
192.0.2.1
192.0.2.2/31
192.0.2.2
192.0.2.3
192.0.2.4/30
192.0.2.4/31
192.0.2.4
192.0.2.5
192.0.2.6/31
192.0.2.6
192.0.2.7
192.0.2.8/29
192.0.2.8/30
192.0.2.8/31
192.0.2.8
192.0.2.9
192.0.2.10/31
192.0.2.10
192.0.2.11
192.0.2.12/30
192.0.2.12/31
192.0.2.12
192.0.2.13
192.0.2.14/31
192.0.2.14
192.0.2.15

What do you see instead?

192.0.2.0/28
192.0.2.0
192.0.2.0/29
192.0.2.0/30
192.0.2.0/31
192.0.2.1
192.0.2.2
192.0.2.2/31
192.0.2.3
192.0.2.4/30
192.0.2.4/31
192.0.2.4
192.0.2.5
192.0.2.6/31
192.0.2.6
192.0.2.7
192.0.2.8/29
192.0.2.8/30
192.0.2.8/31
192.0.2.8
192.0.2.9
192.0.2.10/31
192.0.2.10
192.0.2.11
192.0.2.12/30
192.0.2.12/31
192.0.2.12
192.0.2.13
192.0.2.14
192.0.2.14/31
192.0.2.15

What version of the product are you using? On what operating system?

ipaddr 2.0.x r97

Please provide any additional information below.

Missing information from README and wiki for potential contributors - eg
what to set as default reviewers for codereview/rietveld, if copyright
assignment required, etc.

See here for an example:

http://code.google.com/p/rietveld/wiki/ForContributors

This piggy backs off of Issue 17
(http://code.google.com/p/ipaddr-py/issues/detail?id=17).

I've noticed the problem actually existing in latest trunk revision as well
(revision 71).

What steps will reproduce the problem?

In [1]: from ipaddr import *

In [2]: addresses = [IP(ip) for ip in IP('::1.1.1.0/120')]

In [3]: addresses.extend([IP(ip) for ip in IP('1.1.1.0/24')])

In [4]: len(addresses)
Out[4]: 512

In [5]: addresses[0]
Out[5]: IPv6('::101:100/128')

In [6]: addresses[-1]
Out[6]: IPv4('1.1.1.255/32')

In [7]: CollapseAddrList(addresses)
Out[7]: [IPv4('1.1.1.0/24')]

What is the expected output? What do you see instead?

In [7]: CollapseAddrList(addresses)
Out[7]: [IPv4('1.1.1.0/24'), IPv6('::101:100/120')]

Or, alternatively (with a better representation of the IPv6 addresses) :-

Out[4]: [IPv4('1.1.1.0/24'), IPv6('::1.1.1.0/120')]

What version of the product are you using? On what operating system?

Windows XP

Please provide any additional information below.

Aside: Is this the right place to be raising these bugs or should we be
raising them against the Python bug tracker now that this project has been
integrated in the the Python 2.7 and 3.1 trees?

Thanks,

Dave M.

What steps will reproduce the problem?
1. ipaddr.IP('192.0.2.0') == ''

What is the expected output? What do you see instead?
This raises NotImplementedError.  It should return False instead.

Please use labels and text to provide additional information.
In Python 2.x, all objects are comparable.  In 3.x, incomparable objects
cause a TypeError.

The following methods:

  BaseIP.__getitem__
  BaseIP.broadcast / BaseIP.broadcast_ext
  BaseIP.hostmask / BaseIP.hostmask_ext
  BaseIP.netmask_ext

return strings or integers. They should return IPv4 objects instead.

The fact that you have separate broadcast and broadcast_ext methods that return 
the integer and 
string forms of a network's broadcast address, for instance, indicates that 
your object model is 
not as clean as it could be. Since the broadcast address is, in fact, an 
address, why not return a 
fully functional IPv4 instance? Users could then do (assuming network is an 
IPv4 instance):

str(network.broadcast) if they want the string form, or could do:

network.broadcast.is_private

or any of the other valid operations on an address.

Returning strings and integers from these methods leads to code duplication and 
does not 
embrace the spirit of object-oriented design.

What steps will reproduce the problem?
1. Try to collapse a /24's worth of IP addresses one by one.

Below is code used to benchmark
{{{
from ipaddr import IP, CollapseAddrList

import timeit

RUNS = 1000
addresses = [IP(ip) for ip in IP('1.1.1.0/24')]

if __name__ == '__main__':
    t1 = timeit.Timer('CollapseAddrList(addresses)', 'from __main__ import 
CollapseAddrList, addresses')
    print "CollapseAddrList: %s s" % t1.timeit(number=RUNS)
}}}

*Before:*
$ python collapse_timeit.py
CollapseAddrList: 64.273168087 s

*After:*
$ python collapse_timeit.py
collapse: 1.20903706551 s


What is the expected output? What do you see instead?

ipaddr should be faster

What version of the product are you using? On what operating system?

using latest ipaddr trunk version on Ubuntu on 2.6Ghz Core 2 Duo.

Please provide any additional information below.

The patch in http://codereview.appspot.com/67107 adds the following 
functionality derived from my own original IPy based code at 
http://code.google.com/p/wadofstuff/source/browse/trunk/python/ip/wadofstuf
f/ip/summarize.py

1. summarize_address_range() which takes a start and finish IP and 
summarizes that range into networks.
2. Allow IPv4/IPv6 objects to be created using a range notation e.g 
1.1.1.0-1.1.1.7. This is used by summarize_address_range() to shortcut its 
main loop.
3. collapse_address_list will collapse ordered sequences of IP addresses 
and call summarize on them.

testHash is defined twice and when I renamed the second one to testHash1 so 
both were run and the first one defined fails because the ipv6 network and 
broadcast are equal.

IPTypeError -> TypeError

(IPAddressExclusionError(Error):
IPAddressIPValidationError(Error):
IPv4IpValidationError(Error):
IPv4NetmaskValidationError(Error):
IPv6IpValidationError(Error):
IPv6NetmaskValidationError(Error):
PrefixlenDiffInvalidError(Error):) -> ValueError

The methods patched with the attached diff are private but they should still 
be a little more robust.

Tests included

regards

Matthew

What steps will reproduce the problem?


Python 2.4.3 (#2, Jul 31 2008, 21:56:52) 
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddr
>>> x = ipaddr.IP('192.0.2.0/24')
>>> x.AddressExclude(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "ipaddr.py", line 283, in AddressExclude
    raise IPAddressExclusionError('Error performing address exclusion: '
ipaddr.IPAddressExclusionError: Error performing address exclusion: s1:
192.0.2.0/25 s2: 192.0.2.128/25 other: 192.0.2.0/24


What is the expected output? What do you see instead?

Expected return value is [].


Please use labels and text to provide additional information.

Hi Peter,

I can't find a public bug tracker for ipaddr, so I thought I'd write to
you.

First off, a documentation bug in version 2.0.0: in the __doc__ for
IPv4Network.__init__, you state that the following are all equivalent:

'192.168.1.1/32'
'192.168.1.1/255.255.255.255'
'192.168.1.1/0.0.0.255'
'192.168.1.1'

but surely the second one should be '192.168.1.1/255.255.255.0'.

Second, a documentation enhancement proposal, also from
IPv4Network.__init__. Currently it says:

Instantiate a new IPv4 network object.
Args:
...
A netmask of '255.255.255.255' is assumed
to be /32 and '0.0.0.0' is assumed to be /0, even though
other netmasks can be expressed both as host- and
net-masks. (255.0.0.0 == 0.255.255.255)


which is (to me) unclear. It seems to be suggesting that 255.0.0.0 is a
hostmask, not a netmask, and 0.255.255.255 is a netmask. Isn't it the
other way around?

As I understand it, if the mask is of the form:

all-ones-followed-by-all-zeroes (e.g. 255.255.255.0)

it is a netmask, and if it is of the form:

all-zeroes-followed-by-all-ones (e.g. 0.255.255.255)

it is a hostmask. Correct? Assuming this is correct, and I'm not
confused, I would suggest being explicit about the decision algorithm
used:

"If the mask (portion after the / in the argument) is given in dotted
quad form, it is treated as a netmask if it starts with a non-zero
field (e.g. /255.0.0.0 == /8) and as a hostmask if it starts with a
zero field (e.g. 0.255.255.255 == /8), with the single exception of an
all-zero mask which is treated as a netmask == /0. If no mask is given,
a default of /32 is used."



Regards,

It'd be nice to easily get the hex for ipv4 addresses for use with
applications that use that such as pxelinux.

http://codereview.appspot.com/7255/show

version: An Integer, 4 or 6. Iif set, don't try to automatically

should read:

version: An Integer, 4 or 6. If set, don't try to automatically

ipaddr.IP('') raises:

  AttributeError: 'IPv6' object has no attribute 'ip'

Similarly, ipaddr.IPv6('') should raise ipaddr.IPv6IpValidationError.