On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. Löwis" <martin@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