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 eric.smith
Recipients anudeepballa07, eric.smith
Date 2020-09-20.17:04:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1600621448.15.0.358922529503.issue41820@roundup.psfhosted.org>
In-reply-to
Content
Please do not include screen shots in bug reports. They've unfriendly to people who use screen readers or other accessibility software. Instead, please copy and paste (or retype, if needed) the text into the comment section.

> '172.16.254.00' *is not* equivalent to '172.16.254.0'

Do you have an RFC or other document that makes that clear? I've never seen an IP address library that makes a distinction between '00' and '0'. But I'm happy to learn something new, if you can point to a standard.

If this were going to be an error, it would be in the call to ipaddress.ip_address() or its equivalent. It would raise ValueError, like it does for other strings that don't represent valid addresses. But for backward compatibility reasons, unless there's a standard that explicitly disallows .00, I doubt we'd change the code to raise an exception. And even if there were a standard that says .00 is not a valid address, I'd be reluctant to make a change here. We could potentially break people's code, and we'd need a very good reason to do that.

Also, is this causing you a practical problem? Is there somewhere you're getting a .00 address and you'd like to treat it as being invalid?
History
Date User Action Args
2020-09-20 17:04:08eric.smithsetrecipients: + eric.smith, anudeepballa07
2020-09-20 17:04:08eric.smithsetmessageid: <1600621448.15.0.358922529503.issue41820@roundup.psfhosted.org>
2020-09-20 17:04:08eric.smithlinkissue41820 messages
2020-09-20 17:04:07eric.smithcreate