RetroSearch Browse

Tue Jun 2 15:22:33 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-June/089822.html

On Mon, 1 Jun 2009 at 18:54, Jake McGuire wrote:
> On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" <martin at v.loewis.de>wrote:
>> As for Clay McLure's issue: I feel it's primarily a matter of taste.
>> I see nothing morally wrong in using the same class for hosts and
>> networks, i.e. representing a host as a network of size 1. I can
>> understand why people dislike that, but I don't see why it would stop
>> people from doing with the library what they want to do.
>
> To the extent that Clay is having issues, it's because ipaddr.py is poorly
> documented, has potentially confusing comments, and he became confused.
> Lesser issues are that ipaddr.py doesn't work the way he wants and that ip
> addressing is inherently subtle.
>
> Looking at the code in detail shows that ipaddr.IP/IPv4/IPv6 objects always
> represent *networks*.  He wants one particular address out of that network,
> and that requires using __getitem__ or using IP.ip_ext. Neither is
> particularly intuitive.
>
>>>> import ipaddr
>>>> ip = ipaddr.IPv4('10.33.11.17')
>>>> ip
> IPv4('10.33.11.17/32')
>>>> ip[0]
> '10.33.11.17'

Actually I find that very intuitive if I understand that the objects
are always networks.

>>>> ip.ip_ext
> '10.33.11.17'

That's not intuitive :)

> This feels much more like poor documentation than wide-ranging conceptual
> flaws.
>
> I could put this in the tracker, but I'm not sure if that's appropriate.

I would say yes, put it in the tracker.

--David

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-June/089822.html below:

[Python-Dev] Issues with Py3.1's new ipaddr