On Mon, Jun 1, 2009 at 9:03 PM, pmoody <report@bugs.python.org> wrote:

>> 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.
>
> I'm not sure what you're trying to do here, can you elaborate?

Let's say I have a UI that prompts users for two pieces of
information: interface address, and network mask. I then take those
two strings and make ipaddr.IPv4 objects out of them. This lets me
validate their correctness, and lets me perform convenient
calculations and tests (things the ipaddr library has done well).
Next, I take the IPv4 objects, coerce them to strings, and pass them
to ifconfig to configure an interface.

Assuming the user has supplied this information:

Interface address = '192.168.1.1'
Network mask = '255.255.255.0'

the following would get passed to ifconfig:

ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32

Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.

We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?

>> 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")
>
> i'm not sure what's onerous about this code.  you're missing a
> try/except around ipaddr.IP(), but otherwise it seems fine.

Your definition of onerous apparently differs from mine :)

In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.

> it's actually already been included, but that's beside the point.  I'm
> now asking you a second time to submit bug reports if there are issues
> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
> not.  yelling here doesn't actually do anything productive.

Rest assured, I've opened one issue and will open one or two more
before the night is out.

I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.

Cheers,

Clay