Changes by Antoine Pitrou pit...@free.fr:
--
stage: needs patch - patch review
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
___
Antoine Pitrou added the comment:
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.
--
Added file:
pmoody added the comment:
fine by me. this has been on my todo list forever by $payingjob and $family
have prevented me from devoting any time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
Roundup Robot added the comment:
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.
Antoine Pitrou added the comment:
Thanks for the approval, Peter!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
Changes by Jon Foster jongfos...@users.sourceforge.net:
--
nosy: +jongfoster
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
___
___
Kiyoshi Aman added the comment:
I would instead suggest a cidr or netmask kwarg, rather than accepting a tuple
as first argument.
--
nosy: +Kiyoshi.Aman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
Nick Coghlan added the comment:
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
pmoody added the comment:
Sorry. I thought I'd uploaded this earlier. I'm working on a version that
pushes the parsing into _split_optional_netmask
--
Added file: http://bugs.python.org/file28402/issue16531-2.patch
___
Python tracker
Antoine Pitrou added the comment:
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
Antoine Pitrou added the comment:
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)
--
___
Python tracker rep...@bugs.python.org
pmoody added the comment:
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
--
keywords: +patch
Added file:
pmoody added the comment:
on it.
I'm not a huge fan of integer args for the first argument because of possible
confusion between v4/v6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
___
___
Serhiy Storchaka added the comment:
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)
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
keywords: +easy
nosy: +ezio.melotti
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16531
___
New submission from Antoine Pitrou:
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 =
Nick Coghlan added the comment:
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
Antoine Pitrou added the comment:
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
19 matches
Mail list logo