classification
Title: ipaddress.hosts() doesn't return anything on a /32 "network"
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8, Python 3.7, Python 3.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Lord Anton Hvornum, eric.smith, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-09-26 19:00 by Lord Anton Hvornum, last changed 2017-09-26 21:05 by Lord Anton Hvornum. This issue is now closed.

Messages (9)
msg303063 - (view) Author: Lord Anton Hvornum (Lord Anton Hvornum) Date: 2017-09-26 19:00
https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network.hosts

I couldn't find anywhere in the documentation mentioning the fact that doing the following would return nothing:

>>> import ipaddress
>>> net = ipaddress.ip_network('127.0.0.1/32')
>>> list(net.hosts())
[]

For all intense and purposes, that network still contains hosts.
That being one single lonely host of '127.0.0.1'.

It's illogical to not return any hosts if there actually are one or more in there.
Now the programmer has to do a one-off-check to see if this particular defined network (of a huge list usually)
happens to end with /32, then it needs to treat the item not as a defined network (even tho it is with a netmask),
but rather strip the netmask and treat it as a single host entity.. It makes no sense if you're iterating over a huge list of network infrastructure.
msg303070 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-09-26 20:08
This is documented.

 hosts()

    Returns an iterator over the usable hosts in the network. The usable hosts are all the IP addresses that belong to the network, except the network address itself and the network broadcast address.

>>> import ipaddress
>>> ipaddress.ip_network('127.0.0.1/32').network_address
IPv4Address('127.0.0.1')
>>> ipaddress.ip_network('127.0.0.1/32').broadcast_address
IPv4Address('127.0.0.1')
msg303072 - (view) Author: Lord Anton Hvornum (Lord Anton Hvornum) Date: 2017-09-26 20:16
This is still a very strange behavior and I can't see why this still
shouldn't return a IP address.
if the broadcast, network and host address are all the same, that should
call for a exceptional behavior from the library.
Because 127.0.0.1/32 is still a usable host address, and it's a way of
isolating a host on a network device for instance, but it's still a host
address in there.. Or am i loosing my marbles?

On Tue, Sep 26, 2017 at 10:08 PM Serhiy Storchaka <report@bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> This is documented.
>
>  hosts()
>
>     Returns an iterator over the usable hosts in the network. The usable
> hosts are all the IP addresses that belong to the network, except the
> network address itself and the network broadcast address.
>
> >>> import ipaddress
> >>> ipaddress.ip_network('127.0.0.1/32').network_address
> IPv4Address('127.0.0.1')
> >>> ipaddress.ip_network('127.0.0.1/32').broadcast_address
> IPv4Address('127.0.0.1')
>
> ----------
> nosy: +serhiy.storchaka
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31597>
> _______________________________________
>
msg303073 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-09-26 20:19
Because this is a definition of this method.
msg303074 - (view) Author: Lord Anton Hvornum (Lord Anton Hvornum) Date: 2017-09-26 20:22
And this definition is some how immutable?

On Tue, Sep 26, 2017 at 10:19 PM Serhiy Storchaka <report@bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> Because this is a definition of this method.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31597>
> _______________________________________
>
msg303075 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2017-09-26 20:33
Yes, due to backward compatibility constraints, the behavior is immutable.

You might be able to argue for another method, say all_hosts(), or something. Or maybe even a optional parameter to hosts() that defaults to the existing behavior, but if provided, lets you select a new behavior.

What I would not support is a change to hosts() (or a new method) that treats a /32 network specially.
msg303076 - (view) Author: Lord Anton Hvornum (Lord Anton Hvornum) Date: 2017-09-26 20:46
I was actually just thinking about the same thing, why not just add a
optional flag to the already existing function.
I get that people are way into backward compatibility, and I won't get into
a religious fight over that particular topic as long as there's a fix for
this honestly strange behavior. (It's some Windows mentality saying a /32
network doesn't contain any hosts when you come from a network background).

Seeing as this is apparently a touchy subject, I won't even try to submit a
patch for this because I will screw this up.
So I politely ask someone with more intricate knowledge of this library,
it's history and use to add a totally optional flag that returns the single
host on this very narrow network called /32.

On Tue, Sep 26, 2017 at 10:33 PM Eric V. Smith <report@bugs.python.org>
wrote:

>
> Eric V. Smith added the comment:
>
> Yes, due to backward compatibility constraints, the behavior is immutable.
>
> You might be able to argue for another method, say all_hosts(), or
> something. Or maybe even a optional parameter to hosts() that defaults to
> the existing behavior, but if provided, lets you select a new behavior.
>
> What I would not support is a change to hosts() (or a new method) that
> treats a /32 network specially.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31597>
> _______________________________________
>
msg303078 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2017-09-26 20:53
You lost me at "some Windows mentality". I come from a networking background.

Sorry, I don't care enough about this issue to pursue it.
msg303079 - (view) Author: Lord Anton Hvornum (Lord Anton Hvornum) Date: 2017-09-26 21:05
Historically Windows have struggled with /32 assigned networks.
Trying to push such a network address to a Windows machine has usually (not
all cases) rendered it connection-less, where as switches, routers, *nix
etc have never had any major issues with the logic of a /32 network host
isolation.

Anyway, it was a slight joke/peck on the history of networking.

On Tue, Sep 26, 2017 at 10:53 PM Eric V. Smith <report@bugs.python.org>
wrote:

>
> Eric V. Smith added the comment:
>
> You lost me at "some Windows mentality". I come from a networking
> background.
>
> Sorry, I don't care enough about this issue to pursue it.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31597>
> _______________________________________
>
History
Date User Action Args
2017-09-26 21:05:49Lord Anton Hvornumsetmessages: + msg303079
2017-09-26 20:53:21eric.smithsetmessages: + msg303078
2017-09-26 20:46:30Lord Anton Hvornumsetmessages: + msg303076
2017-09-26 20:33:43eric.smithsetnosy: + eric.smith
messages: + msg303075
2017-09-26 20:22:23Lord Anton Hvornumsetmessages: + msg303074
2017-09-26 20:19:51serhiy.storchakasetmessages: + msg303073
2017-09-26 20:16:39Lord Anton Hvornumsetmessages: + msg303072
2017-09-26 20:08:18serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg303070

resolution: not a bug
stage: resolved
2017-09-26 19:00:01Lord Anton Hvornumcreate