Foster Snowhill <pyt...@pen.gy> added the comment:
I've stumbled upon this myself, and had a go at fixing it, before looking up this issue. My approach ended up being a bit different: 1. I rewrote the existing _reverse_pointer() methods, so that they'd handle both addresses and networks, instead of defining separate methods for the IPvXNetwork classes. 2. Trying to generate a reverse pointer for a prefix that doesn't align with the granularity of reverse pointers (8 bits for IPv4, 4 bits for IPv6) will raise an exception instead of returning a more general prefix. I would like to bring up point 2 for discussion, since it differs from both of the other PRs submitted regarding this issue. For example, let's take an example subnet 127.45.240.0/20. The other solutions here propose generating a reverse pointer like "45.127.in-addr.arpa", i.e. returning a reverse pointer to a bigger subnet that includes the original one. When you convert that reverse pointer back into a network, you get 127.45.0.0/16. It doesn't match the original network, thus you lose some information about it. I'd like to propose to be more strict about it (or at least, make the strict behaviour an option) to avoid unintentional loss of precision when generating reverse pointers in these cases. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30528> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
