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

[Paul Moore]

2009/6/2 Bugbee, Larry <larry.bugbee at boeing.com>:
>> > > I don't hear a public outcry - only a single complainer.
>> >
>> > Clay repeatedly pointed out that other people have objected
>> > to ipaddr and been ignored.  It's really, really disappointing
>> > to see you continue to ignore not only them, but the repeated
>> > attempts Clay has made to point them out.
>>
>> I don't have time to argue this issue, but I agree with
>> essentially everything Clay has said in this thread....
>
> I too agree.  If it is not ready, it is not ready.  Please don't create
> problems for others.  Remove the lib until it is ready.

I don't write the sort of code that requires this module very often,
so I guess I class as an example of a casual user who would assume the
stdlib module was "best practice", and expect to use it naively to
avoid the more obvious "gotchas".

I've just now read the documentation for the first time (after reading
this thread) and for what it's worth here are my thoughts:

* 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.

* I'm sorry, but ip_ext is a hopeless name. It makes no sense to me.
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?

* 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.

* 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.
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.

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.

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.

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

Paul.