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

[Clay McClure]

On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

>> That doesn't solve much. IPv4 objects still always use CIDR notation
>> when coerced to strings, meaning that IP addresses will always be
>> rendered with a trailing "/32".
>
> That's not true:
>
> py> x = ipaddr.IP("30.40.50.60")
> py> print(x.ip_ext_full)
> 30.40.50.60

Thankfully the authors have provided this obscure and strangely-named
method to get at the correct string representation of an IP address,
but sadly their __str__ method -- which is the Pythonic way to get
string representations of objects -- fails in this regard because they
have only one class representing two distinct concepts.

I could probably make ipaddr work in my application; that is not the
issue (at least in my mind). The issue is that I shouldn't have to
work around design flaws in the library when they're simple enough to
fix before the library is bundled with the stdlib. I do not see the
utility of including ipaddr when my choice as a user is to either use
its strangely-named methods instead of obvious Pythonic conventions,
or to write my own library.

>> Such notation is unacceptable in
>> real-world applications that (correctly) distinguish between address
>> and network.
>
> So use a different notation that is also supported by the library.

I'm not referring to my software here -- I'm referring to applications
like ifconfig that expect addresses to be formatted properly. If the
default string representation produced by the ipaddr library does not
match the canonical representation expected by software that has
existed as long as IP itself, that indicates to me the library is
doing something wrong.

> Because we *are* sure that it in fact represents a good base upon which
> to build.

You certainly seem convinced. I could not disagree more.

Clay