This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author claymation
Recipients Rhamphoryncus, benjamin.peterson, claymation, ezio.melotti, giampaolo.rodola, gregory.p.smith, gvanrossum, loewis, mattsmart, oubiwann, pitrou, pmoody, pnasrat, shields
Date 2009-06-01.20:33:13
SpamBayes Score 1.3647174e-05
Marked as misclassified No
Message-id <8657ee3f0906011333p28c10403p803ba5dcda563442@mail.gmail.com>
In-reply-to <4A240B3E.5070408@v.loewis.de>
Content
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.

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.

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.

Clay
History
Date User Action Args
2009-06-01 20:33:16claymationsetrecipients: + claymation, gvanrossum, loewis, gregory.p.smith, Rhamphoryncus, pitrou, giampaolo.rodola, benjamin.peterson, ezio.melotti, mattsmart, shields, pmoody, pnasrat, oubiwann
2009-06-01 20:33:14claymationlinkissue3959 messages
2009-06-01 20:33:13claymationcreate