call for testing - experimental version ipaddr.

29 views
Skip to first unread message

Peter Moody

unread,
Feb 2, 2012, 8:49:24 PM2/2/12
to ipaddr-py-dev
I've made some backwards incompatible changes to ipaddr as a result of
ongoing email conversations about pep 3144 (the pep about including
ipaddr in python stdlib), and i'd like to get some user feedback if
possible.

Documentation of the new API can be found here
(http://code.google.com/p/ipaddr-py/wiki/Using3144). At a high level,
the major change is that networks objects can only represent networks
(eg, 192.168.0.0/16) and the introduction of a new pair of interface
classes which represent the hybrid address/network object (eg,
192.168.0.1/16).

I've added a featured download,
(http://ipaddr-py.googlecode.com/files/3144.tar.gz), or you can
checkout the code directly with

git clone https://code.google.com/p/ipaddr-py/

which leads me to the other change; I've moved the backend from svn to git. :)

Let me know what you think.

Cheers,
peter

--
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038

Clay McClure

unread,
Mar 21, 2012, 1:56:10 AM3/21/12
to ipaddr...@googlegroups.com
On Thursday, February 2, 2012 8:49:24 PM UTC-5, Peter Moody wrote:

I've made some backwards incompatible changes to ipaddr as a result of
ongoing email conversations about pep 3144 (the pep about including
ipaddr in python stdlib), and i'd like to get some user feedback if
possible.

Overall this looks great. A few quibbles:

>>> IPv4Network('192.168.1.0/24').numhosts
256

yet

>>> for ip in IPv4Network('192.168.1.0/24').iterhosts():
...    print ip

yields only 254 addresses. I would argue that they should agree. 

I might also change the syntax (unless you've already ruled this out for some reason):

>>> len(IPv4Network('192.168.1.0/24'))
256

>>> for ip in IPv4Network('192.168.1.0/24'):
...     print ip

Some users will want iteration to produce all IPs in a network; others will only want to get the "assignable" addresses; still others will want to get the "usable" addresses for hosts (excluding routers and what not). In these cases, you could perhaps use a slicing syntax:

>>> for ip in IPv4Network('192.168.1.0/24')[1:-2]:
...     print ip

which returns all but the first and last addresses.

Otherwise I think it looks great.

Cheers,

Clay

Peter Moody

unread,
Mar 23, 2012, 12:48:41 PM3/23/12
to Clay McClure, ipaddr...@googlegroups.com
Thanks, Clay.

On Tue, Mar 20, 2012 at 10:56 PM, Clay McClure <cl...@daemons.net> wrote:
> On Thursday, February 2, 2012 8:49:24 PM UTC-5, Peter Moody wrote:
>
>> I've made some backwards incompatible changes to ipaddr as a result of
>> ongoing email conversations about pep 3144 (the pep about including
>> ipaddr in python stdlib), and i'd like to get some user feedback if
>> possible.
>
>
> Overall this looks great. A few quibbles:
>
>>>> IPv4Network('192.168.1.0/24').numhosts
> 256
>
> yet
>
>>>> for ip in IPv4Network('192.168.1.0/24').iterhosts():
> ...    print ip
>
> yields only 254 addresses. I would argue that they should agree.
>
> I might also change the syntax (unless you've already ruled this out for
> some reason):
>
>>>> len(IPv4Network('192.168.1.0/24'))
> 256

This isn't supported because it doesn't work for IPv6. IIRC, __len__
returns an int and that overflows for networks > /96. Guido
pretty-heavily poo-poohed this (as I go back and look at the original
thread with him from '07).

>>>> for ip in IPv4Network('192.168.1.0/24'):
> ...     print ip
>
> Some users will want iteration to produce all IPs in a network; others will
> only want to get the "assignable" addresses; still others will want to get
> the "usable" addresses for hosts (excluding routers and what not). In these
> cases, you could perhaps use a slicing syntax:
>
>>>> for ip in IPv4Network('192.168.1.0/24')[1:-2]:
> ...     print ip
>
> which returns all but the first and last addresses.
>
> Otherwise I think it looks great.

I still have to apply some polish to this version; I'll see about
incorporating what I can from these suggestions. Time's been a little
scarce recently with an upcoming wedding.

> Cheers,
>
> Clay

Clay McClure

unread,
Mar 23, 2012, 1:56:41 PM3/23/12
to Peter Moody, ipaddr...@googlegroups.com
On Fri, Mar 23, 2012 at 12:48 PM, Peter Moody <pmo...@google.com> wrote:

> I might also change the syntax (unless you've already ruled this out for
> some reason):
>
>>>> len(IPv4Network('192.168.1.0/24'))
> 256

This isn't supported because it doesn't work for IPv6. IIRC, __len__
returns an int and that overflows for networks > /96. Guido
pretty-heavily poo-poohed this (as I go back and look at the original
thread with him from '07).

OK, then something like IPv4Network('192.168.1.0/24').num_addresses is fine. Personally, I prefer "addresses" to "hosts", since the addresses may not map to hosts.

I still have to apply some polish to this version; I'll see about
incorporating what I can from these suggestions. Time's been a little
scarce recently with an upcoming wedding.

Great, thanks, and congratulations!

Cheers,

Clay
 

Greg

unread,
Mar 23, 2012, 11:30:15 AM3/23/12
to ipaddr-py-dev
Peter:

Only bug I've noticed is that it fails when building on Python 3.2.

I've attached patches to the defect report (http://code.google.com/p/
ipaddr-py/issues/detail?id=94) that should fix this issue, especially
since reading the PEP docs, that a 3000 PEP is "Intended for Python
3.x"

I'm just getting back into code development, and this would be my
first official "Hey, I can fix this" in Python, so I'm appreciative of
any guidance, corrections, or advice I can get.

Greg Matyola

On Feb 2, 9:49 pm, Peter Moody <pmo...@google.com> wrote:
> I've made some backwards incompatible changes to ipaddr as a result of
> ongoing email conversations about pep 3144 (the pep about including
> ipaddr in python stdlib), and i'd like to get some user feedback if
> possible.
>
> Documentation of the new API can be found here
> (http://code.google.com/p/ipaddr-py/wiki/Using3144). At a high level,
> the major change is that networks objects can only represent networks
> (eg, 192.168.0.0/16) and the introduction of a new pair of interface
> classes which represent the hybrid address/network object (eg,
> 192.168.0.1/16).
>
> I've added a featured download,
> (http://ipaddr-py.googlecode.com/files/3144.tar.gz), or you can
> checkout the code directly with
>
> git clonehttps://code.google.com/p/ipaddr-py/
Reply all
Reply to author
Forward
0 new messages