When you write code that deals with IPv4 addresses, every so often you wind up in situations where you want to convert addresses in conventional text form to unsigned 32-bit integers and manipulate them in various ways (and then convert the results back to normal notation). This is something I've been dealing with recently , so I've been working on this today.

Python doesn't have any standard library functions that directly do these conversions. You can write your own code for this (but it's just long enough to be annoying), or alternately you can glue together the socket and struct modules to get what you want.

socket.inet_aton doesn't directly convert an IP address to a 32-bit integer; instead it convert it to a 32-bit packed binary string. To get an actual integer, we need to unpack the string with struct.unpack . The one gotcha is that inet_aton returns results in network byte order , so if we want our IP addresses as natural numbers (in host byte order) we need to tell struct to do this conversion. To convert the other way we can use socket.inet_ntoa , which also has the same requirement of working in network byte order.

So we wind up with the following small and almost symmetric routines:

def ip_to_uint32(ip):
   t = socket.inet_aton(ip)
   return struct.unpack("!I", t)[0]

def uint32_to_ip(ipn):
   t = struct.pack("!I", ipn)
   return socket.inet_ntoa(t)

If you want your unsigned 32-bit integer IPv4 addresses in network byte order, leave out the ! in the unpack() and pack() format strings. Probably you don't, though, unless you are doing peculiar things with them.

(Given what this does, there is no point in using socket.inet_pton instead of inet_aton ; we intrinsically deal only with IPv4 addresses anyways, so extra generality is actually counterproductive.)

PS: if you slap together code like this, it's a good idea to test it with simple IPv4 addresses that you can easily work out the numeric values for by hand. I almost skipped doing this and thus almost missed that inet_aton returns results in network byte order instead of host byte order. Such a mistake is entertaining, but only from a suitable distance.