Add prefixlen parameter to IPvXNetwork classes

[GoogleCodeExporter]

http://codereview.appspot.com/3848042

Linked codereview patch to add prefixlen parameter to IPvXNetwork constructors. 
This is useful when instantiating IPvXNetwork objects from a database where the 
prefix and prefix length are both stored as integers.

Also adds strict=True checking when constructing from ints, or packed bytes.

Original issue reported on code.google.com by maddi...@lightbound.net on 3 Jan 2011 at 6:03

[GoogleCodeExporter]

I'm not going to implement this, if for no other reason than because this leads 
to

>>> ipaddr.IPNetwork('1.1.1.0/24', prefixlen=16)

which, no matter what is returned, is bound to confuse.

Original comment by pmo...@google.com on 4 Jan 2011 at 4:51

• Changed state: WontFix

[GoogleCodeExporter]

What if it threw an exception if 2 netmasks were supplied? Or make the 
prefixlen= parameter only apply if constructing from integer/packed bytes and 
throw an exception if it's supplied when constructing from a string? The only 
'in the box' workaround for constructing from integers to supply a netmask is 
to do an initial conversion of the integer to an IPvXAddress, then convert that 
to string, then concatenate the netmask, and construct a new IPvXNetwork 
object, which is kind of wasteful.

Original comment by maddi...@lightbound.net on 4 Jan 2011 at 2:33

[GoogleCodeExporter]

Like I said, one way or the other, it's going to be confusing.

It sounds like what you need is an efficient way to turn an int into packed
bytes which you can then use with the socket interface to turn into a
string.

eg:

IPv4Network('1.1.1.1/24')

while using socket for this intermediate stage might seem like an
unnecessary step, it's far less confusing than dealing two possibly
conflicting prefixlen's in the constructor.  And since everything between 0
and 4294967295 is both a valid v4 and v6 int, I think it makes most sense to
not guess which packed representation the user wants.

Would that do?

Original comment by pmo...@google.com on 4 Jan 2011 at 4:42

[GoogleCodeExporter]

I've put up a fix in r198

Original comment by pmo...@google.com on 7 Jan 2011 at 5:23

• Changed state: Fixed