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.

Author Lord Anton Hvornum
Recipients Lord Anton Hvornum, serhiy.storchaka
Date 2017-09-26.20:16:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAG2iS6pZ1OTW-psfd1dC=UYm-sETD1qZ9C4ho5qh=nC_LdDVnw@mail.gmail.com>
In-reply-to <1506456498.64.0.394147662359.issue31597@psf.upfronthosting.co.za>
Content
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>
> _______________________________________
>
History
Date User Action Args
2017-09-26 20:16:39Lord Anton Hvornumsetrecipients: + Lord Anton Hvornum, serhiy.storchaka
2017-09-26 20:16:39Lord Anton Hvornumlinkissue31597 messages
2017-09-26 20:16:39Lord Anton Hvornumcreate