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 exhuma
Recipients exhuma, ncoghlan, pmoody
Date 2014-03-02.13:18:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
In-reply-to
Content
The ipaddress module always returns ``False`` when testing if a network is contained in another network. However, I feel this should be a valid test. No? Is there any reason why this is fixed to ``False``?

In case not, here's a patch which implements this test.

Note that by design, IP addresses networks can never overlap "half-way". In cases where this should return ``False``, you either have a network that lies completely "to the left", or completely "to the right". In the case it should return ``True`` the smaller network is always completely bounded by the larger network's network- and broadcast address.

I needed to change two containment tests as they were in conflict with this change. These tests were ``self.v6net not in self.v6net`` and ``self.v4net not in self.v4net``. The reason these two failed is that the new containment test checks the target range *including* broadcast and network address. So ``a in a`` always returns true.

This could be changed by excluding one of the two boundaries, and by that forcing the "containee" to be smaller than the "container". But it would make the check a bit more complex, as you would need to add an exception for the case that both are identical.

Backwards compatibility is a good question. Strictly put, this would break it. However, I can't think of any reason why anyone would expect ``a in a`` to be false in the case of IP-Addresses.

Just as a side-note, I currently work at our national network provider and am currently implementing a tool dealing with a lot of IP-Addresses. We have run into the need to test ``net in net`` a couple of times and ran into bugs because the stdlib returns ``False`` where you technically expect it to be ``True``.
History
Date User Action Args
2014-03-02 13:18:19exhumasetrecipients: + exhuma, ncoghlan, pmoody
2014-03-02 13:18:19exhumasetmessageid: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
2014-03-02 13:18:19exhumalinkissue20825 messages
2014-03-02 13:18:18exhumacreate