[issue22941] IPv4Interface arithmetic changes subnet mask
Søren Løvborg added the comment:
As mentioned python-dev, I'm not entirely sold on raising an exception on
overflow.
To recap the mailing list discussion, there was general agreement that the
current behavior is a bug, suggesting that there's no need to go through the
depreciation process. There's been three proposals for correct behavior, though:
A) To simply ignore the subnet mask: 10.0.0.255/24 + 1 = 10.0.1.0/24
B) To wrap around inside the subnet: 10.0.0.255/24 + 1 = 10.0.0.0/24
C) To raise exception.
First, note what happens if we overflow an IPv4Address:
ipaddress.IPv4Address('255.255.255.255') + 1
Traceback (most recent call last):
...
ipaddress.AddressValueError: 4294967296 (= 2**32) is not permitted
as an IPv4 address
At least that suggests a type of exception to use in proposal C.
There was not much support for the idea of wrapping (B); for which I see three
reasons:
1) No identified use case where this effect would be desirable.
2) It's implicit rather than explicit: The addition operator usually does not
imply modular arithmetic.
3) It's inconsistent with IPv4Address, which doesn't wrap.
That leaves the question of raising an exception (C), or not (A).
Now, I used IPv4Interface + 1 to mean Give me the IP next to the current one
in the current subnet, knowing from the context that the address would be
valid and available.
host = ipaddress.IPv4Interface('10.0.0.2/24')
peer = host + 1
In this context, an exception makes a lot of sense, as it would certainly have
been an error if I'd overflowed the subnet.
However, I can also imagine situations in which overflowing would be valid and
expected, e.g. as a way to skip to the same IP in the next subnet:
ip = ipaddress.IPv4Interface('10.0.0.1/24')
ip + ip.network.num_addresses
IPv4Interface('10.0.1.1/24')
There's an additional issue with raising an exception, and that is that it
still won't catch the errors as intended. In my use case:
host = ipaddress.IPv4Interface('10.0.0.254/24')
peer = host + 1
This wouldn't overflow and not trigger an exception, but the resulting peer
address is still invalid (it's the subnet broadcast address, not a host
address).
As for consistency with IPv4Address, I can argue for either proposal:
A) An IPv4Interface behaves exactly like an IPv4Address, except that it also
has an associated subnet mask. (This is essentially how it's currently
documented).
C) Overflowing an IPv4Interface raises AddressValueError just like with
IPv4Address.
All in all, I'm in favor of keeping things simple and go with solution A, since
C prevents a reasonable use, and doesn't actually catch out of bounds errors
anyway. I'm open to being convinced otherwise, though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22941
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22941] IPv4Interface arithmetic changes subnet mask
Søren Løvborg added the comment:
I take it the silence means that the patch is neither obviously good nor
obviously bad. :-)
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)'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22941
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22941] IPv4Interface arithmetic changes subnet mask
New submission from 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')
Changing this breaks backwards compatibility; though since the ipaddress module
was provisional until recently and the behavior is undocumented, I hope it's
not too late to change.
--
components: Library (Lib)
messages: 231670
nosy: kwi.dk
priority: normal
severity: normal
status: open
title: IPv4Interface arithmetic changes subnet mask
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22941
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22941] IPv4Interface arithmetic changes subnet mask
Søren Løvborg added the comment:
Proposed implementation patch attached. If this has any interest, I'll look
into expanding the patch to include documentation and unit tests.
Resulting 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')
--
keywords: +patch
Added file: http://bugs.python.org/file37277/ipaddress.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22941
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python extension using a C library with one 'hello' function
I'm not sure if it fits your needs, but we are very happy with calling c libs directly from python using ctypes: https://docs.python.org/2/library/ctypes.html It requires a few extra lines in Python to handle the parameter and return types. import ctypes result = ctypes.windll.Hello.hello() -- https://mail.python.org/mailman/listinfo/python-list
Re: First time I looked at Python was(...)
Hi ... That's great and you're one person with enough /Intelligence/ to participate in the projects I described you. You can think about the solution, logs , how the information is organized,etc. You're certainly one of the persons! I'm not writing more ... I have been on this mail group for a relatively short time and I'm chocked to see the amount of needless posts in general. Is it too much to ask for some mail-group discipline? Carlos and some others, please phrase your questions or requests concisely and clearly. Making a post that initiates a flood of questions and discussions is clearly inefficient, specially if it is beside the core essence of a Python language group and probably besides the poster's own goal too. It wastes a lot peoples time and it devalues the usefulness of the mail group. There was some entertainment in it though, but for that purpose I seek other sources. -- https://mail.python.org/mailman/listinfo/python-list
Re: The pysync library - Looking for the code, but all download links are broken
I think what you are looking for can be found at: http://www.google.com/codesearch/p?hl=en#RncWxgazS6A/pysync-2.24/test/testdata.pyq=pysync%20package:%22http://minkirri.apana.org.au/~abo/projects/pysync/arc/pysync-2.24.tar.bz2%22%20lang:python or http://shortlink.dk/58664133 I am not affiliated with the project in any way, and I can't find a way to download the entire thing in one go. So if you do salvage a working copy please let me (and the rest of the community) know. //Søren - Peng - Pedersen -- http://mail.python.org/mailman/listinfo/python-list
