call for testing - experimental version ipaddr.

[Peter Moody]

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]

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]

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]

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]

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/