Clay is basically correct. The ipaddr.py API is missing important features, and it would probably be a mistake to add it to the python standard library if that means we'd have to maintain compatibility for the indefinite future.
From a maintenance point of view, these two statements don't really relate. Yes, adding it to the standard library means that compatibility must be maintained (not for the indefinite future, but in a very strong sense). But no, that doesn't mean that it cannot have new features.
Adding new features would not have to break compatibility, and, in many real-world cases of existing libraries, didn't. For the net-vs-host issue, I think a backwards-compatible solution is possible: just give the IP() function an option parameter that makes it reject a netmask during parsing.
Like all largeish python projects, we wrote a library to do IP address manipulation. In our case, it's a whopping 64 lines long. [...] In fact, if I was starting a new project from scratch with similar requirements, I'd probably write my own library instead of using ipaddr.
That was my feeling as well when ipaddr was first offered. It's just not an important library, and people will continue to roll their own for some time. OTOH, with ipaddr in the standard library, people will also start contributing extensions that make it support their use cases, so it should grow a wider application area than it currently supports. Regards, Martin