homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Wicken, era, ethan.furman, lukasz.langa, ncoghlan, pmoody, xiang.zhang
Priority: normal Keywords: patch

Created on 2016年11月01日 07:02 by era, last changed 2022年04月11日 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 18757 merged Wicken, 2020年03月02日 23:49
PR 25532 closed Wicken, 2021年04月22日 19:59
PR 25533 closed Wicken, 2021年04月22日 20:01
PR 25536 merged Wicken, 2021年04月22日 20:05
Messages (15)
msg279855 - (view) Author: (era) Date: 2016年11月01日 07:02
I would expect the following code to return ['10.9.8.8'] but it returns an empty list.
 yosemite-osx$ python3
 Python 3.5.1 (default, Dec 26 2015, 18:08:53) 
 [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import ipaddress
 >>> list(ipaddress.ip_network('10.9.8.7/32').hosts())
 []
This seems to happen for every /32 address. I'm guessing the logic which wants to exclude the gateway and broadcast addresses from a block should treat a /32 as a special case.
I tried to look for a previous bug submission but I could not find one. As such, it seems peculiar if this has not been reported before. Is this actually expected behavior by some rule I am overlooking?
I tested on Linux 3.4 and OSX Yosemite Homebrew / Python 3.5.1.
msg279856 - (view) Author: (era) Date: 2016年11月01日 07:04
(Meh, silly typo, of course the expected output is ['10.9.8.7'], sorry about that!)
msg279858 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016年11月01日 07:16
hosts() won't return the network address itself and the network broadcast address. So for 10.9.8.7/32, it should return [].
msg279859 - (view) Author: (era) Date: 2016年11月01日 08:16
@xiang.zhang thanks for the quick reply.
I find this behavior surprising. If I process a list of addresses, like
 ips = (
 '10.9.8.7/32'
 '10.11.12.8/28'
 )
 for test in ['10.9.8.7', '10.11.12.10']:
 if test in [str(y) for x in ips for y in ipaddress.ip_network(x).hosts()]:
 print('{0} found'.format(test))
 else:
 print('{0} not found'.format(test))
I would expect both addresses to print "found", but that's not how the current implementation works.
I agree that the /28 should not include the gateway and broadcast addresses, but I would not expect the explicitly listed /32 address to completely disappear from the output.
Are my expectations incorrect? For code like this, what should I use instead, if not hosts()?
msg279860 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016年11月01日 09:03
I am not sure. Actually there is a special case for mask 31, you can see #27863. Its result includes both the network and broadcast address. Add Nick to see his opinion.
FYI, ipaddress (ipaddr in Py2) always return empty for 32. But there is other library returning network address for 32, for example netaddr.
msg279862 - (view) Author: (era) Date: 2016年11月01日 09:31
Quick googling did not turn up anything like a credible authoritative reference for this, but in actual practice, I have seen /32 used to designate a single individual IP address in CIDR notation quite a lot.
I can see roughly three options:
 1. Status quo. Silently surprise users who expect this to work.
 2. Silently fix. Hard-code /32 to return a range of one IP address.
 3. Let users choose. Similarly to the "strict=True" keyword argument in the constructor method, the code could allow for either lenient or strict semantics.
By the by, I don't see how the bug you linked to is relevant here, did you mistype the bug number? #27863 is about _elementtree
msg279865 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016年11月01日 09:41
Sorry, it's #27683.
msg279867 - (view) Author: Alyssa Coghlan (ncoghlan) * (Python committer) Date: 2016年11月01日 10:03
I think this is an area where ipaddress just inherited ipaddr's behaviour without challenging it.
As Peter isn't currently particularly active, and I stepped back from ipaddress maintenance some time ago (since I don't work heavily enough with raw IP addresses to have the right design instincts to arbitrate edge cases like this), I'd suggest raising both this and #27683 on python-dev, pointing out that we used to have the "/31" special case (treating it the same as "/30") and inadvertently lost it in some other refactoring, but have never special cased "/32".
msg314183 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2018年03月21日 02:13
I fixed #27683 since it looks more like an oversight and regression to me instead of a deliberate change. I'd like the behaviour to be consistent across versions. As for "/32", it needs discussion or some expert makes a choice.
msg355956 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2019年11月04日 15:59
I came across this /32 issue today trying to iterate over the hosts in 127.0.0.1/32. I think it's fair to say that any /32 network has precisely one host, and that host should by returned by IPv4Network().hosts().
msg363221 - (view) Author: Pete Wicken (Wicken) * Date: 2020年03月02日 23:57
I've had a go at implementing this. I did not implement for IPv6 as this was not mentioned here, but it seems like it would make sense for it as well. I can add that in too if you like.
msg363249 - (view) Author: Pete Wicken (Wicken) * Date: 2020年03月03日 09:21
Ok it was bugging me that they were different, so I also added the same logic for IPv6Networks.
msg363778 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2020年03月09日 22:33
New changeset 8e9c47a947954c997d4b725f4551d50a1d896722 by Pete Wicken in branch 'master':
bpo-28577: Special case added to IP v4 and v6 hosts for /32 and /128 networks (GH-18757)
https://github.com/python/cpython/commit/8e9c47a947954c997d4b725f4551d50a1d896722
msg368638 - (view) Author: Pete Wicken (Wicken) * Date: 2020年05月11日 18:12
The patch for this has been merged - I guess this can be closed now?
msg391983 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2021年04月26日 19:57
New changeset 10ad7eb2ef61a2ba99341c804c8c960e4f284621 by Pete Wicken in branch '3.8':
[3.8] bpo-28577: Special case added to IP v4 and v6 hosts for /32 and /128 networks (GH-18757) (#25536)
https://github.com/python/cpython/commit/10ad7eb2ef61a2ba99341c804c8c960e4f284621
History
Date User Action Args
2022年04月11日 14:58:38adminsetgithub: 72763
2021年04月26日 19:57:07lukasz.langasetnosy: + lukasz.langa
messages: + msg391983
2021年04月26日 19:56:19lukasz.langasetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2021年04月22日 20:05:06Wickensetpull_requests: + pull_request24255
2021年04月22日 20:01:51Wickensetpull_requests: + pull_request24252
2021年04月22日 19:59:34Wickensetpull_requests: + pull_request24251
2020年05月11日 18:12:17Wickensetmessages: + msg368638
2020年03月09日 22:35:17ethan.furmansetversions: + Python 3.7
2020年03月09日 22:33:52ethan.furmansetmessages: + msg363778
2020年03月03日 09:21:22Wickensetmessages: + msg363249
2020年03月02日 23:57:49Wickensetmessages: + msg363221
2020年03月02日 23:49:57Wickensetkeywords: + patch
nosy: + Wicken

pull_requests: + pull_request18112
stage: patch review
2019年11月04日 15:59:13ethan.furmansetnosy: + ethan.furman
messages: + msg355956
2018年03月21日 02:14:00xiang.zhangsetresolution: not a bug -> (no value)
stage: resolved -> (no value)
messages: + msg314183
versions: + Python 3.8, - Python 3.7
2016年11月01日 10:03:58ncoghlansetnosy: + pmoody
messages: + msg279867
2016年11月01日 09:41:28xiang.zhangsetmessages: + msg279865
2016年11月01日 09:31:42erasetmessages: + msg279862
2016年11月01日 09:03:15xiang.zhangsetstatus: closed -> open
versions: + Python 3.7, - Python 3.4, Python 3.5
nosy: + ncoghlan

messages: + msg279860

type: behavior
2016年11月01日 08:16:05erasetmessages: + msg279859
2016年11月01日 07:16:34xiang.zhangsetstatus: open -> closed

nosy: + xiang.zhang
messages: + msg279858

resolution: not a bug
stage: resolved
2016年11月01日 07:04:44erasetmessages: + msg279856
2016年11月01日 07:02:04eracreate

AltStyle によって変換されたページ (->オリジナル) /