RetroSearch Browse

Thu Mar 12 13:37:16 CET 2015 · http://mail.python.org/pipermail/python-dev/2015-March/138760.html

Hi,

I'm looking for feedback on issue 22941, "IPv4Interface arithmetic changes subnet mask".

As stated in the bug, I'd be happy to write a patch, if anyone would comment on my proposal.

http://bugs.python.org/issue22941

Thank you,
Søren Løvborg

---

Addition and subtraction of integers are documented for ipaddress.IPv4Address and ipaddress.IPv6Address, but also work for IPv4Interface and IPv6Interface (though the only documentation of this is a brief mention that the Interface classes inherit from the respective Address classes). That's good.

The problem is that adding/subtracting an integer to an Interface object changes the subnet mask (to max_prefixlen), something which is 1) not documented and 2) not the least surprising result.

>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/32')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/128')

Proposed behavior:

>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/8')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/64')

It all comes down to a judgment call: is this a bug, or expected (but undocumented) behavior?

In PEP 387 lingo: Is this a "reasonable bug fix"? Or is it a "design mistake", thus calling for a FutureWarning first, and the actual change later?

    >>> ipaddress.IPv4Interface('1.2.3.4/16') + 1
    __main__:1: FutureWarning: Arithmetic on IPv4Interface objects will
    change in Python 3.6. If you rely on the current behavior, change
    'interface + n' to 'IPv4Interface(interface.ip + n, 32)'

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2015-March/138760.html below:

[Python-Dev] Request for comments: [issue22941] IPv4Interface arithmetic changes subnet mask