ipaddr-py - Project Hosting on Google Code

Last 30 days Dec 18, 2009 issue 51 (NameError when checking prefixlen syntax of IPv6Network) reported by hb...@ele.uri.edu - What steps will reproduce the problem? 1. Create an IPv6Network object from any (invalid) IPv6 string containing more than one /. >>> import ipaddr >>> ipaddr.IPv6Network("::a:b/120/120") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "ipaddr.py", line 1773, in __init__ raise AddressValueError(ipaddr) NameError: global name 'ipaddr' is not defined What is the expected output? What do you see instead? IPv6Network.__init__ correctly detects that this is invalid syntax and tries to raise an AddressValueError on the address, but provides an invalid argument. What version of the product are you using? On what operating system? SVN revision 129, Ubuntu Linux 9.10. Please provide any additional information below. Patch and test case are attached. What steps will reproduce the problem? 1. Create an IPv6Network object from any (invalid) IPv6 string containing more than one /. >>> import ipaddr >>> ipaddr.IPv6Network("::a:b/120/120") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "ipaddr.py", line 1773, in __init__ raise AddressValueError(ipaddr) NameError: global name 'ipaddr' is not defined What is the expected output? What do you see instead? IPv6Network.__init__ correctly detects that this is invalid syntax and tries to raise an AddressValueError on the address, but provides an invalid argument. What version of the product are you using? On what operating system? SVN revision 129, Ubuntu Linux 9.10. Please provide any additional information below. Patch and test case are attached. Dec 17, 2009 issue 50 (Invalid exception names) reported by mike.volokhov - 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 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 Dec 16, 2009 issue 49 ('module' object has no attribute 'IPv4') Status changed by pmo...@google.com - hey, sorry for not seeing this earlier. You're right, the documentation on the exampleusage page is for the 1.x version of the library. It's undergone a major re- write and I never actually updated the wiki documentation. Status: Accepted hey, sorry for not seeing this earlier. You're right, the documentation on the exampleusage page is for the 1.x version of the library. It's undergone a major re- write and I never actually updated the wiki documentation. Status: Accepted Dec 16, 2009 ExampleUsage Wiki page edited by pmo...@google.com - Revision r130 Edited wiki page through web user interface. Revision r130 Edited wiki page through web user interface. Dec 16, 2009 issue 38 (ipaddr: Documentation bug and enhancement suggestion) Status changed by pmo...@google.com - Status: Fixed Status: Fixed Dec 16, 2009 issue 38 (ipaddr: Documentation bug and enhancement suggestion) Owner changed by pmo...@google.com - r129 Owner: pmo...@google.com r129 Owner: pmo...@google.com Dec 16, 2009 r129 ( + finally getting around to documentation suggestions from ...) committed by pmo...@google.com - + finally getting around to documentation suggestions from issue38 (from Steven D'Aprano) + finally getting around to documentation suggestions from issue38 (from Steven D'Aprano) Dec 09, 2009 r128 ( + change RunTimeError to a simple assertion based on sugges...) committed by pmo...@google.com - + change RunTimeError to a simple assertion based on suggestion from mat smart. + change RunTimeError to a simple assertion based on suggestion from mat smart. Older Dec 02, 2009 issue 48 (IPv4 Mapped Addresses Inconsistency) commented on by rlaager - ipaddr.IPv6Address('::ffff:192.168.0.0') also blows up, though in a different way--it throws an exception. This can be fixed by changing line 1411 from: ip_int = (ip_int << 16) + int(field, 16) to: ip_int = (ip_int << 16) + int(field or '0', 16) ipaddr.IPv6Address('::ffff:192.168.0.0') also blows up, though in a different way--it throws an exception. This can be fixed by changing line 1411 from: ip_int = (ip_int << 16) + int(field, 16) to: ip_int = (ip_int << 16) + int(field or '0', 16) Nov 30, 2009 issue 49 ('module' object has no attribute 'IPv4') reported by mathieu.geli - 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' 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' Nov 28, 2009 issue 46 (fix exceptions) Status changed by pmo...@google.com - should be fixed in r126/r127 Status: Fixed should be fixed in r126/r127 Status: Fixed Nov 28, 2009 r127 ( + comments from matt smart: change the address exclusion...) committed by pmo...@google.com - + comments from matt smart: change the address exclusion error to RunTimeError exception docstrings typo in docstring. + comments from matt smart: change the address exclusion error to RunTimeError exception docstrings typo in docstring. Nov 28, 2009 r126 ( + clean up the exceptions raised by ipaddr.) committed by pmo...@google.com - + clean up the exceptions raised by ipaddr. + clean up the exceptions raised by ipaddr. Nov 23, 2009 issue 48 (IPv4 Mapped Addresses Inconsistency) reported by rlaager - 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. 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. Nov 17, 2009 issue 30 (string based support for function and method arguments) Status changed by pmo...@google.com - not going to implement this. leads to inconsistent interface (or a lot of extra code to keep a consistent interface) and doesn't seem strictly pythonic. >>> [1] + 2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "int") to list Status: WontFix not going to implement this. leads to inconsistent interface (or a lot of extra code to keep a consistent interface) and doesn't seem strictly pythonic. >>> [1] + 2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "int") to list Status: WontFix Nov 17, 2009 issue 39 (Bad netmask not reported as error) Status changed by pmo...@google.com - checked in r125 to fix this. Status: Fixed checked in r125 to fix this. Status: Fixed Nov 17, 2009 r125 ( + first stab at issue 39. the _valid_mask_octets aren't ne...) committed by pmo...@google.com - + first stab at issue 39 . the _valid_mask_octets aren't needed for ipv6 since netmasks aren't writtne in the same way. + first stab at issue 39 . the _valid_mask_octets aren't needed for ipv6 since netmasks aren't writtne in the same way. Nov 04, 2009 issue 47 (global name 'long' is not defined) Owner changed by pmo...@google.com - Owner: pmo...@google.com Owner: pmo...@google.com Nov 04, 2009 issue 47 (global name 'long' is not defined) Status changed by pmo...@google.com - I've been putting off setting up a fully-py3k version of ipaddr just b/c I've been busy and haven't installed py3k anywhere. I'll get this done. Status: Accepted I've been putting off setting up a fully-py3k version of ipaddr just b/c I've been busy and haven't installed py3k anywhere. I'll get this done. Status: Accepted Nov 04, 2009 issue 39 (Bad netmask not reported as error) commented on by pmo...@google.com - http://codereview.appspot.com/148042/show http://codereview.appspot.com/148042/show Nov 04, 2009 issue 46 (fix exceptions) commented on by pmo...@google.com - http://codereview.appspot.com/148041/show http://codereview.appspot.com/148041/show Nov 04, 2009 issue 47 (global name 'long' is not defined) reported by nepenthesdev - 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? 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. Nov 03, 2009 issue 46 (fix exceptions) reported by pmo...@google.com - IPTypeError -> TypeError (IPAddressExclusionError(Error): IPAddressIPValidationError(Error): IPv4IpValidationError(Error): IPv4NetmaskValidationError(Error): IPv6IpValidationError(Error): IPv6NetmaskValidationError(Error): PrefixlenDiffInvalidError(Error):) -> ValueError IPTypeError -> TypeError (IPAddressExclusionError(Error): IPAddressIPValidationError(Error): IPv4IpValidationError(Error): IPv4NetmaskValidationError(Error): IPv6IpValidationError(Error): IPv6NetmaskValidationError(Error): PrefixlenDiffInvalidError(Error):) -> ValueError Nov 03, 2009 issue 45 (ipv4-ipv6 mixed notation (x:x:x:x:x:x:d.d.d.d) raise a Value...) commented on by marco.giusti - i have to admit that i did not read all the rfc and i did not well understand if only "IPv4-Compatible IPv6 Address", section 2.5.5.1, is deprecated or even "IPv4-Mapped IPv6 Address", section 2.5.5.2, is deprecated too but section 2.2 does not mention nothing about it. even if those address representations are deprecated the code is already written so i think is a good idea do not remove the code but still support they, but really you should consider a more experienced's thoughts because i do not understand all the implications of that. i have to admit that i did not read all the rfc and i did not well understand if only "IPv4-Compatible IPv6 Address", section 2.5.5.1, is deprecated or even "IPv4-Mapped IPv6 Address", section 2.5.5.2, is deprecated too but section 2.2 does not mention nothing about it. even if those address representations are deprecated the code is already written so i think is a good idea do not remove the code but still support they, but really you should consider a more experienced's thoughts because i do not understand all the implications of that. Nov 02, 2009 issue 43 (IPXNetwork should provide an iterator for its subnets) Status changed by pmo...@google.com - fixed in r124 Status: Fixed fixed in r124 Status: Fixed Nov 02, 2009 r124 ( + provide an iterator for looping through subnets. most use...) committed by pmo...@google.com - + provide an iterator for looping through subnets. most useful for large subnets, like v6 subnets. patch by Marco Giutsi. + provide an iterator for looping through subnets. most useful for large subnets, like v6 subnets. patch by Marco Giutsi. Oct 30, 2009 issue 45 (ipv4-ipv6 mixed notation (x:x:x:x:x:x:d.d.d.d) raise a Value...) Owner changed by pmo...@google.com - Owner: pmo...@google.com Owner: pmo...@google.com Oct 30, 2009 issue 45 (ipv4-ipv6 mixed notation (x:x:x:x:x:x:d.d.d.d) raise a Value...) Status changed by pmo...@google.com - i might be missing something here, but the '::a.b.c.d' v4 compat address format was deprecated by rfc 4291. I'm not sure what the best way to handle deprecated addresses should be, but I certainly don't want to be on the hook to support their notation. Status: Accepted i might be missing something here, but the '::a.b.c.d' v4 compat address format was deprecated by rfc 4291. I'm not sure what the best way to handle deprecated addresses should be, but I certainly don't want to be on the hook to support their notation. Status: Accepted Oct 30, 2009 issue 44 ( Duplicated code in IPv6Network.__init__ ) Status changed by pmo...@google.com - fixed in r123 Status: Fixed fixed in r123 Status: Fixed Oct 30, 2009 r123 ( + unecessary sanitization check in IPv6Network. by Marco...) committed by pmo...@google.com - + unecessary sanitization check in IPv6Network. by Marco Guitsi. + unecessary sanitization check in IPv6Network. by Marco Guitsi. Oct 30, 2009 issue 44 ( Duplicated code in IPv6Network.__init__ ) Status changed by pmo...@google.com - LGTM. i'm going to apply the patch. Status: Accepted LGTM. i'm going to apply the patch. Status: Accepted Oct 30, 2009 r122 ( + require that address or network objects be passed into __...) committed by pmo...@google.com - + require that address or network objects be passed into __contains__ and overlaps (as opposed to also accepting strings/ints). more consistent interface. easier to maintain, etc. Suggestion from Phillip. + require that address or network objects be passed into __contains__ and overlaps (as opposed to also accepting strings/ints). more consistent interface. easier to maintain, etc. Suggestion from Phillip. Oct 20, 2009 issue 45 (ipv4-ipv6 mixed notation (x:x:x:x:x:x:d.d.d.d) raise a Value...) reported by marco.giusti - 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? 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 Oct 20, 2009 issue 43 (IPXNetwork should provide an iterator for its subnets) commented on by marco.giusti - Now i did, i only hope that all my havings do not became google's havings or google's lawyers will not knock at my door. Please, consider to rename the function in something more coherent like 'itersubnets'. Now i did, i only hope that all my havings do not became google's havings or google's lawyers will not knock at my door. Please, consider to rename the function in something more coherent like 'itersubnets'. Oct 19, 2009 issue 43 (IPXNetwork should provide an iterator for its subnets) commented on by pmo...@google.com - hey marco, thanks for sending the patch! before I dig into this, I wanted to check to see if you'd 'signed' the contributor license agreement. Same goes for the other patch you've sent in. one of these days, I'll get around to finding out where the list of already-signed-cla lives so I don't have to ask. cheers, /peter hey marco, thanks for sending the patch! before I dig into this, I wanted to check to see if you'd 'signed' the contributor license agreement. Same goes for the other patch you've sent in. one of these days, I'll get around to finding out where the list of already-signed-cla lives so I don't have to ask. cheers, /peter Oct 17, 2009 issue 44 ( Duplicated code in IPv6Network.__init__ ) reported by marco.giusti - Please provide any additional information below. In iPv6Network.__init__ a double check is performed, here[1] the patch. [1] http://codereview.appspot.com/130092 Please provide any additional information below. In iPv6Network.__init__ a double check is performed, here[1] the patch. [1] http://codereview.appspot.com/130092 Oct 17, 2009 issue 43 (IPXNetwork should provide an iterator for its subnets) reported by marco.giusti - 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. >>> 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 Oct 10, 2009 issue 42 ([Patch] Fix for Network equality) Status changed by pmo...@google.com - fixed in r118 >>> ipaddr.IPNetwork('1.1.1.1/25') == ipaddr.IPNetwork('1.1.1.10/25') True >>> ipaddr.IPNetwork('1.1.1.1/25') < ipaddr.IPNetwork('1.1.1.10/25') False >>> ipaddr.IPNetwork('1.1.1.1/25') <= ipaddr.IPNetwork('1.1.1.10/25') True Status: Fixed fixed in r118 >>> ipaddr.IPNetwork('1.1.1.1/25') == ipaddr.IPNetwork('1.1.1.10/25') True >>> ipaddr.IPNetwork('1.1.1.1/25') < ipaddr.IPNetwork('1.1.1.10/25') False >>> ipaddr.IPNetwork('1.1.1.1/25') <= ipaddr.IPNetwork('1.1.1.10/25') True Status: Fixed Oct 08, 2009 issue 37 (_BaseV6._string_from_ip_int() raises misleading exception if...) Status changed by pmo...@google.com - r116 Status: Fixed r116 Status: Fixed Oct 08, 2009 issue 41 (testHash fails) Status changed by pmo...@google.com - r121 Status: Fixed r121 Status: Fixed Oct 08, 2009 r121 ( + __hash__ now hashes the hex() of ._ip for _BaseIP. this ...) committed by pmo...@google.com - + __hash__ now hashes the hex() of ._ip for _BaseIP. this should make it a little more robust + __hash__ now hashes the hex() of ._ip for _BaseIP. this should make it a little more robust Oct 08, 2009 r120 ( + don't need the python2.6) committed by pmo...@google.com - + don't need the python2.6 + don't need the python2.6 Oct 08, 2009 r119 ( + the comparison tests when hashing don't make sense since ...) committed by pmo...@google.com - + the comparison tests when hashing don't make sense since __hash__ values are dependant upon version and platform. + the comparison tests when hashing don't make sense since __hash__ values are dependant upon version and platform. Oct 08, 2009 r118 ( + _BaseNet comparisons now ignore the ._ip attribute when d...) committed by pmo...@google.com - + _BaseNet comparisons now ignore the ._ip attribute when doing comparisons/hashing/etc. + _BaseNet comparisons now ignore the ._ip attribute when doing comparisons/hashing/etc. Oct 07, 2009 issue 40 (overlaps() should test other against self too) Status changed by pmo...@google.com - fixed in r117. also included ability to pass other in as a string too. thanks! Status: Fixed fixed in r117. also included ability to pass other in as a string too. thanks! Status: Fixed Oct 07, 2009 r117 ( + fix up overlaps to be compliant with how IPy handles it ...) committed by pmo...@google.com - + fix up overlaps to be compliant with how IPy handles it (test self in other and other in self) + include ability to pass in a string rather than just another network object. + fix up overlaps to be compliant with how IPy handles it (test self in other and other in self) + include ability to pass in a string rather than just another network object. Oct 07, 2009 issue 36 (A couple more int() calls that need to be wrapped with try/e...) Status changed by pmo...@google.com - fixed in r116. thanks! Status: Fixed fixed in r116. thanks! Status: Fixed Oct 07, 2009 r116 ( + make IPv4's _ip_int_from_string more robust. patch fro...) committed by pmo...@google.com - + make IPv4's _ip_int_from_string more robust. patch from mattimustang + make IPv4's _ip_int_from_string more robust. patch from mattimustang Oct 06, 2009 issue 41 (testHash fails) Status changed by pmo...@google.com - fair enough. I'll check out making hash use the hex() value. Status: Accepted fair enough. I'll check out making hash use the hex() value. Status: Accepted Oct 06, 2009 issue 41 (testHash fails) commented on by digitalx...@gmail.com - True, but the failure was (at least on my system Vista64, py25 for win32) that has(IPv6Netowrk('2001:658:22a:cafe:200:0:0:1/64').network) == (IPv6Network('2001:658:22a:cafe:200:0:0:1/64').broadcast) which would mean the Network has a range of 0, but there are in fact IP's in there when you loop over the network, so that points is a bug in the _BaseIP.__hash__ method. I just did some further testing >>> ipv6 = IPv6Network('2001:658:22a:cafe:200:0:0:1/64') >>> print ipv6.network._ip == ipv6.broadcast._ip False >>> print hash(ipv6.network) == hash(ipv6.broadcast) True >>> print ipv6.network == ipv6.broadcast False The current _BaseIP.__hash__ just does hash(self._ip) which in this particular case means the two different longs are hashing equal at the python level. After some testing I propose the __hash__ be changed to hash(hex(self._ip)) or hash(self._string_from_ip_int(self._ip)) True, but the failure was (at least on my system Vista64, py25 for win32) that has(IPv6Netowrk('2001:658:22a:cafe:200:0:0:1/64').network) == (IPv6Network('2001:658:22a:cafe:200:0:0:1/64').broadcast) which would mean the Network has a range of 0, but there are in fact IP's in there when you loop over the network, so that points is a bug in the _BaseIP.__hash__ method. I just did some further testing >>> ipv6 = IPv6Network('2001:658:22a:cafe:200:0:0:1/64') >>> print ipv6.network._ip == ipv6.broadcast._ip False >>> print hash(ipv6.network) == hash(ipv6.broadcast) True >>> print ipv6.network == ipv6.broadcast False The current _BaseIP.__hash__ just does hash(self._ip) which in this particular case means the two different longs are hashing equal at the python level. After some testing I propose the __hash__ be changed to hash(hex(self._ip)) or hash(self._string_from_ip_int(self._ip))

issue 41 (testHash fails) commented on by digitalx...@gmail.com - True, but the failure was (at least on my system Vista64, py25 for win32) that has(IPv6Netowrk('2001:658:22a:cafe:200:0:0:1/64').network) == (IPv6Network('2001:658:22a:cafe:200:0:0:1/64').broadcast) which would mean the Network has a range of 0, but there are in fact IP's in there when you loop over the network, so that points is a bug in the _BaseIP.__hash__ method. I just did some further testing >>> ipv6 = IPv6Network('2001:658:22a:cafe:200:0:0:1/64') >>> print ipv6.network._ip == ipv6.broadcast._ip False >>> print hash(ipv6.network) == hash(ipv6.broadcast) True >>> print ipv6.network == ipv6.broadcast False The current _BaseIP.__hash__ just does hash(self._ip) which in this particular case means the two different longs are hashing equal at the python level. After some testing I propose the __hash__ be changed to hash(hex(self._ip)) or hash(self._string_from_ip_int(self._ip))

True, but the failure was (at least on my system Vista64, py25 for win32) that has(IPv6Netowrk('2001:658:22a:cafe:200:0:0:1/64').network) == (IPv6Network('2001:658:22a:cafe:200:0:0:1/64').broadcast) which would mean the Network has a range of 0, but there are in fact IP's in there when you loop over the network, so that points is a bug in the _BaseIP.__hash__ method. I just did some further testing >>> ipv6 = IPv6Network('2001:658:22a:cafe:200:0:0:1/64') >>> print ipv6.network._ip == ipv6.broadcast._ip False >>> print hash(ipv6.network) == hash(ipv6.broadcast) True >>> print ipv6.network == ipv6.broadcast False The current _BaseIP.__hash__ just does hash(self._ip) which in this particular case means the two different longs are hashing equal at the python level. After some testing I propose the __hash__ be changed to hash(hex(self._ip)) or hash(self._string_from_ip_int(self._ip))

Last 30 days

Older