[Python-Dev] Issues with Py3.1's new ipaddr

[R. David Murray]

On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
> * I'd expect separate classes for "an IP address" and "a subnet" -
> I've no problem with that expectation being wrong, but I'd like some
> documentation as to *why* a single class is appropriate. (More
> generally, the documentation seems pretty terse). Seeing "/32" all
> over the place in the examples reinforces my feeling.

Yeah, the documentation needs a lot of work.  Since this is a
subject area I know something about, hopefully I can make time to
contribute something.

> * I'm sorry, but ip_ext is a hopeless name. It makes no sense to me.

My guess is that it is "ip external representation", as opposed
to the internal representation as an integer.  I agree that the
name is terrible.

> My first thought was "why not just use ip?" until I realised that
> (contrary to the expectations of a naive user) an IP address is an
> integer and that (uncommon???) usage gets to use the "ip" property
> name. But still, why not "ip_str" at least?

Agreed; unless you are talking to C code, I'd think you'd want the string
representation.  This seems like an odd design decision.

> * IP('1.2.3.4') vs IP('1.2.3.0/255.255.255.0') - it seems entirely
> sane for the former to have a .ip/.ip_str/.ip_ext property, but
> bizarre for the latter to. Explain the principles all you like, it
> still seems peculiar.

It may seem peculiar, but IMO it is correct.  The ip is the zero
of the network, and is just as valid an IP as an ip inside the
network with the same netmask.

> * To be honest, I'd prefer to have the _ext versions be named without
> a suffix, and the currently unsuffixed versions have an _int suffix.

I agree.  I wish I'd looked at this back when it was put in, but I was
a lot busier with other things then :)

> That may reflect my naive expectations, and experts may well expect
> the integer forms to be the more easily accessible, but is the library
> intended for expert or non-expert users? (That's not a rhetorical
> question). The people I work with (DBAs) deal with IP addresses all
> the time, but almost certainly aren't even aware that they aren't
> strings. If I did a poll, I guess most wouldn't even know that the
> components were restricted to 0-255! I can't imagine them being
> comfortable with this module.

If they don't know that, and they only work with IP addresses in the most
trivial form, then I don't think they would need any of the services this
library provides.  That doesn't mean the library is for "experts", but
it does mean it's for people who need to manipulate IP addresses within
the context of networks.  (If all you need to do is move IP addresses
around, just keep them as strings.)

Hmm.  Except I suppose they could use the input validation checking...

I think we've already agreed that adding a flag to IP saying 'no netmask'
is a good idea...if the object created that way would by default output
without a netmask, then the trivial needs of your DBA's would probably
be met.

> Reading the documentation, I'd probably end up assuming it was for
> experts, and writing my own code rather than using it - which is
> probably a sign of failure for the module.
>
> Simple example. If I want to scan all the IP addresses on my network
> (my IP address is 192.168.1.101) I'd probably write:
>
>    for i in range(253):
>        ip = '192.168.1.' + str(i+1)
>        ...
>
> - and to heck with generality.
>
> Even after reading the documentation, I've *no idea* how I would use
> the ipaddr module to do this better. Let alone in as few lines.

     net = ipaddr.IP('192.168.1.0/24'):
     for i in range(253):
         ip = net[i]
         ...

So, that's one example that needs to be added to the docs.

I'd have liked to write that as:

     for ip in ipaddr.IP('192.168.1.0/24')[:253]:
         ...

but apparently it doesn't support slicing (time for an RFE :)

> My requirements certainly aren't important enough to drive the design
> of the stdlib - and it's possible that these issues are *precisely*
> the sort of things that can be fixed with documentation and
> backward-compatible changes - but I also think that a bit more time to
> address such things would be reasonable.

If they are documentation and backward compatible changes (and I believe
they are), why not get the thing into the field so more people can
provide feedback and RFEs?

> And I also apologise for not checking the module out sooner. Blame an
> assumption that my trivial needs would "obviously" be covered...

Yeah, me too.

--David