On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure <report@bugs.python.org> wrote:
>
> Clay McClure <clay@daemons.net> added the comment:
>
> 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

I suppose that might be the case if you didn't know how to use ipaddr.
 knowing that ipaddr accepts an ipaddress/netmask, I'd pass it

my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask))

and then check for any exceptions.  I'd then ifconfig en0 str(my_ip)

> 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.

so ipaddr doing this validation for the user actually could make some
sense, but this could be fixed by something as easy

  ipaddr.IP(ip, network=False)
or
  ipaddr.IP(net, network=True)

anyway (more below)...

>> 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.

cool, I see that you did that. as an aside, this probably isn't the
best place for continued discussion on ipaddr. ipaddr has already been
shipped with python, so i'm not sure that debate on it's inclusion is
able to influence that decision.  All of the folks who've worked on
ipaddr + the python committer are on ipaddr-py-dev@googlegroups.com
(looks like you are too), so might I suggest we continue this
discussion there?

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

I think debate is healthy, too.  but I measure my success at a debate
by my ability to convince other people of my side. I find I have
better success when I listen other people and respond with respect.
yelling promotes neither of those.

Cheers,
/peter

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