Author claymation
Recipients Rhamphoryncus, benjamin.peterson, claymation, ezio.melotti, giampaolo.rodola, gregory.p.smith, gvanrossum, loewis, mattsmart, oubiwann, pitrou, pmoody, pnasrat, r.david.murray, shields
Date 2009-06-02.00:47:44
SpamBayes Score 0.00135855
Marked as misclassified No
Message-id <8657ee3f0906011747u213e7727w205f568189960636@mail.gmail.com>
In-reply-to <4A24401B.7080901@v.loewis.de>
Content
On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis <report@bugs.python.org> wrote:

> Do you have an application in mind where this lack of distinction
> would prevent writing the application in a straight-forward way?
> IOW, could you do something if they were distinct that you can't
> do because they are not?

Consider applications that use ipaddr.IPv4 objects to configure
network interfaces:

ifconfig: 255.255.255.0/32: bad value

That's because ipaddr wrongly appends a prefix length to all
ipaddr.IPv4 objects, even those representing addresses, which do not
have prefix lengths.

Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:

address = ipaddr.IP(input)

if isinstance(address, ipaddr.IPv4):
    if address.prefixlen != 32:
        raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
    if address.prefixlen != 128:
        raise TypeError("Expecting IP address, not network")

Given its myriad quirks, it is really rather surprising that ipaddr is
being considered for inclusion in the Python stdlib.

Clay
History
Date User Action Args
2009-06-02 00:47:46claymationsetrecipients: + claymation, gvanrossum, loewis, gregory.p.smith, Rhamphoryncus, pitrou, giampaolo.rodola, benjamin.peterson, ezio.melotti, mattsmart, shields, pmoody, pnasrat, r.david.murray, oubiwann
2009-06-02 00:47:44claymationlinkissue3959 messages
2009-06-02 00:47:44claymationcreate