On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure <report@bugs.python.org> wrote:
>
> Clay McClure <clay@daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis <report@bugs.python.org> wrote:
>
>>> My hope is that now that a library has been selected, it can be improved
>>> before Python 2.7 and 3.1 ship.
>>
>> That is fairly unlikely. The 3.1 release candidate has been produced,
>> so the only options possible at this point are to either go ahead with
>> what is in the code, or withdraw the library from 3.1 if it can be
>> demonstrated to have severe flaws.
>
> False
>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True
>
> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.

I don't see these a fundamentally different, I guess.  can you
demonstrate how this equivalency makes ipaddr unusable?

> ipaddr has many other quirks that, while not technically flaws, are
> design warts that deserve to be fixed before its target audience is
> amplified by its inclusion in the stdlib.

I haven't seen any new issues on code.google.com (and I haven't heard
of any being reported on the python bugtracker), so since you're using
this thread to report issues, can you elaborate?

> To those arguing for ipaddr's inclusion in the stdlib, how many of you
> will actually use ipaddr to develop software? As an actual developer
> of network scanning and discovery software, I can tell you that I
> would rather roll my own library than use ipaddr as it exists today.

have used it to develop software and will continue to use it to
develop software.

Cheers,
/peter

> Clay
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>