homepage

I am in a situation where I'm building an IPNetwork from separate address and mask information. So roughly I'd like to write either:
 addr = IPAddress('192.168.0.0')
 network = IPNetwork((addr, '255.255.0.0'))
or
 addr = '192.168.0.0'
 network = IPNetwork((addr, '255.255.0.0'))
Of course it seems like this would be equivalent to:
 network = IPNetwork('%s/%s' % (addr, '255.255.0.0.'))
(but more user-friendly :-))

Sounds reasonable, especially as it also allows networks and interfaces
with prefixes other than "/32" or "/128" to be easily constructed based on
integer address values.
Should we also allow integers as the second argument, with the same prefix
length meaning as the corresponding string?

> Sounds reasonable, especially as it also allows networks and interfaces
> with prefixes other than "/32" or "/128" to be easily constructed based on
> integer address values.
> 
> Should we also allow integers as the second argument, with the same prefix
> length meaning as the corresponding string?
IMO, yes.

How about ipaddress.IPv4Network((3232235520, 16)), ipaddress.IPv4Network((3232235520, 65535)) and ipaddress.IPv4Network((3232235520, 4294901760))?
>>> ipaddress.IPv4Address(3232235520)
IPv4Address('192.168.0.0')
>>> ipaddress.IPv4Address(65535)
IPv4Address('0.0.255.255')
>>> ipaddress.IPv4Address(4294901760)
IPv4Address('255.255.0.0')
>>> ipaddress.IPv4Network('192.168.0.0/0.0.255.255')
IPv4Network('192.168.0.0/16')
>>> ipaddress.IPv4Network('192.168.0.0/255.255.0.0')
IPv4Network('192.168.0.0/16')

on it.
I'm not a huge fan of integer args for the first argument because of possible confusion between v4/v6.

This patch is for (address, prefixlen). I now see that the original request was (address, netmask). I'll fix this up. In the meantime, let me know if this is what you had in mind.
Cheers,
peter

> This patch is for (address, prefixlen). I now see that the original
> request was (address, netmask). I'll fix this up. In the meantime, let 
> me know if this is what you had in mind.
This is what I had in mind indeed (except that I was mostly interested in the netmask case :-)).

Oh, I was also interested in IPNetwork((ip_address_object, netmask)).
(that is, given an existing IPAddress object, build a IPNetwork by passing that object + a netmask)

IIRC, construction from existing instances in general is an issue in the current version of the module. One particularly murky question if it were allowed is what should happen if you pass an IPAdapter instance (which already has associated network info) rather than an ordinary IPAddress.
Forcing people to go through an integer or a string in that case, or call one of the explicit conversion methods, forces them to be explicit about the fact that they're deliberate discarding any other information associated with the original object. (Note that I like the 2-tuple idea - I'm just pointing out that allowing an IPAddress object as the first element of that 2-tuple isn't quite as straightforward as it may first appear)

Sorry. I thought I'd uploaded this earlier. I'm working on a version that pushes the parsing into _split_optional_netmask

I would instead suggest a cidr or netmask kwarg, rather than accepting a tuple as first argument.

Updated patch with more tests, documentation updates, and an optimized version of the supernet() that's now 5x faster than the original.
I would like to commit this if there's no further comment.

fine by me. this has been on my todo list forever by $payingjob and $family have prevented me from devoting any time.

New changeset 4e33c343a264 by Antoine Pitrou in branch 'default':
Issue #16531: ipaddress.IPv4Network and ipaddress.IPv6Network now accept an (address, netmask) tuple argument, so as to easily construct network objects from existing addresses.
http://hg.python.org/cpython/rev/4e33c343a264 

Thanks for the approval, Peter!