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.

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')

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>
> _______________________________________
>

Because this is a definition of this method.

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>
> _______________________________________
>

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.

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>
> _______________________________________
>

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.

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>
> _______________________________________
>