j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Thu, 15 Feb 2018 15:14:03 +1100, Steven D'Aprano wrote:
On Thu, Feb 15, 2018 at 11:45:46AM +1100, Chris Angelico wrote:
Except that this computer's IPv4 is not 3232235539, and I never want to enter it that way. I enter it as 192.168.0.19 - as four separate integers.
That's partly convention (and a useful convention: it is less error- prone than 3232235539) and partly that because you're a sys admin who can read the individual subfields of an IP address. I'm not suggesting you ought to change your habit.
But to civilians, 192.168.0.19 is as opaque as 3232235539 or 0xC0A80013 would be.
There was a lengthy discussion (or more than one) about supporting decimal unicode code point literals. Is U+03B1 (GREEK SMALL LETTER ALPHA) somehow less clear than X+945?
192.168.0.19 speaks volumes, but 3232235539 is not only opaque, but also obtuse.
But doing at least some int operations on addresses isn't meaningless:
py> a = ipaddress.ip_address('192.168.0.19') py> a + 1 IPv4Address('192.168.0.20')
py> a = ipaddress.ip_address('192.168.1.255')
py> a + 1 IPv4Address('192.168.1.256')
py> a = ipaddress.ip_address('255.255.255.255')
py> a + 1
Yes, if I were writing a DHCP server, the notion of "the next IP address that meets certain constraints, or an exception if no such address exists" has meaning. But it's not as simple as "ip + 1."