classification
Title: Allow IPNetwork to take a tuple
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Kiyoshi.Aman, asvetlov, ezio.melotti, jongfoster, ncoghlan, pitrou, pmoody, python-dev, serhiy.storchaka
Priority: low Keywords: easy, patch

Created on 2012-11-22 21:59 by pitrou, last changed 2014-05-12 18:37 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
issue16531.patch pmoody, 2012-12-07 04:50 review
issue16531-2.patch pmoody, 2012-12-23 03:38 review
issue16531-3.patch pitrou, 2014-05-12 17:48 review
Messages (15)
msg176129 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-11-22 21:59
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 :-))
msg176137 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-11-22 23:17
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?
msg176151 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-11-23 06:54
> 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.
msg176159 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-23 09:50
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')
msg177025 - (view) Author: pmoody (pmoody) * (Python committer) Date: 2012-12-06 03:56
on it.

I'm not a huge fan of integer args for the first argument because of possible confusion between v4/v6.
msg177067 - (view) Author: pmoody (pmoody) * (Python committer) Date: 2012-12-07 04:50
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
msg177114 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-07 19:22
> 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 :-)).
msg177115 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-07 19:24
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)
msg177934 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-12-22 10:27
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)
msg177964 - (view) Author: pmoody (pmoody) * (Python committer) Date: 2012-12-23 03:38
Sorry. I thought I'd uploaded this earlier. I'm working on a version that pushes the parsing into _split_optional_netmask
msg189205 - (view) Author: Kiyoshi Aman (Kiyoshi.Aman) Date: 2013-05-14 09:48
I would instead suggest a cidr or netmask kwarg, rather than accepting a tuple as first argument.
msg218341 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-05-12 17:48
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.
msg218345 - (view) Author: pmoody (pmoody) * (Python committer) Date: 2014-05-12 18:33
fine by me. this has been on my todo list forever by $payingjob and $family have prevented me from devoting any time.
msg218346 - (view) Author: Roundup Robot (python-dev) Date: 2014-05-12 18:36
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
msg218347 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-05-12 18:37
Thanks for the approval, Peter!
History
Date User Action Args
2014-05-12 18:37:22pitrousetstatus: open -> closed
resolution: fixed
messages: + msg218347

stage: patch review -> resolved
2014-05-12 18:36:53python-devsetnosy: + python-dev
messages: + msg218346
2014-05-12 18:33:34pmoodysetmessages: + msg218345
2014-05-12 18:24:55pitroulinkissue21486 dependencies
2014-05-12 17:48:19pitrousetfiles: + issue16531-3.patch

messages: + msg218341
2014-05-12 17:12:44pitrousetstage: needs patch -> patch review
versions: + Python 3.5, - Python 3.4
2013-09-01 20:16:51jongfostersetnosy: + jongfoster
2013-05-14 09:48:04Kiyoshi.Amansetnosy: + Kiyoshi.Aman
messages: + msg189205
2012-12-23 03:38:39pmoodysetfiles: + issue16531-2.patch

messages: + msg177964
2012-12-22 10:27:27ncoghlansetmessages: + msg177934
2012-12-07 19:24:38pitrousetmessages: + msg177115
2012-12-07 19:22:57pitrousetmessages: + msg177114
2012-12-07 04:50:58pmoodysetfiles: + issue16531.patch
keywords: + patch
messages: + msg177067
2012-12-06 03:56:13pmoodysetmessages: + msg177025
2012-12-03 15:40:37asvetlovsetnosy: + asvetlov
2012-11-23 17:49:00ezio.melottisetkeywords: + easy
nosy: + ezio.melotti

stage: needs patch
2012-11-23 09:50:46serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg176159
2012-11-23 06:55:00pitrousetmessages: + msg176151
2012-11-22 23:17:45ncoghlansetmessages: + msg176137
2012-11-22 21:59:26pitroucreate