j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
> j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
>
>> Daniel Jakots <vigdis+o...@chown.me> writes:
>>
>>> Hi,
>>>
>>> I wanted to add a py3 flavor to net/py-ripe.atlas.tools which depends
>>> on net/py-ripe.atlas.sagan wich itself depends on py-IP, hence this
>>> diff.
>>>
>>> I only tried py-ripe.atlas.tools so please test it, thanks.
>>
>> As I said the tests fail with python3.4 on i386:
>>
>> https://pbot.rmdir.de/3I3_OxgyBOqIqgR3KtBWLw
>>
>> The reason is that IPy.IP() defines a __nonzero__() method, but python
>> 3 tries to use __bool__() instead, falling back to __len__(). Adding
>> a __bool__ method fixes the regress tests, but the len() method
>> remains broken on 32 bits, using python2.7 or python3.4.
>
> So here's a diff including the mentioned fix. It should be reported
> upstream, mentioning the len() problem would be worth it too.
Just so that nobody wastes time on this, the problem about the len()
builtin function calling __len__() is normal and already known by
upstream:
def __len__(self):
"""
Return the length of a subnet.
Called to implement the built-in function len().
It will break with large IPv6 Networks.
Use the object's len() instead.
"""
return self.len()
It's just that it will also break with IPv4 networks 0.0.0.0/0,
0.0.0.0/1 and 128.0.0.0/1, which contain more than INT32_MAX addresses.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
