On Mon, Jun 1, 2009 at 9:39 AM, Clay McClure <report@bugs.python.org> wrote:
>
> Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late
> to continue this discussion. I have no vested interest in either ipaddr or
> netaddr, but I am interested in seeing a well-designed and usable IP
> address library included in the stdlib.

Python 3.1 is as good as shipped.  It is in the release candidate
stage which means no code changes other than bug fixes can go in.

Improvements will have to wait for 2.7 and 3.2.  In the mean time I
suggest writing up improvements as either subclasses of the existing
ipaddr module (so that they can be used both with this standalone
project and with the version shipped in python 3.1).

>> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
>> off-putting than "1.1.1.0/24".
>
> Since networks are commonly represented in at least three forms, the API
> should support at least these:
>
> CIDR/prefix notation: "192.168.1.0/24"
> address+mask notation: "192.168.1.0/255.255.255.0"
> range notation: "192.168.1.0-192.168.1.255"

I think range notation parsing could be implemented pretty easily.

> Access lists and DHCP pools are two common examples of where arbitrary
> address ranges are useful.
>
> At least three concepts deserve first-class treatment in any meaningful
> IP address library:
>
> * addresses
> * ranges of addresses
> * networks
>
> To conflate these is a mistake.
>
> My hope is that now that a library has been selected, it can be improved
> before Python 2.7 and 3.1 ship. Now is the best time to make
> backwards-incompatible API changes; once ipaddr ships with the stdlib,
> we're stuck with it. If it remains as-is, it will be deadweight for those app
> developers like myself who prefer an API that more accurately reflects
> the problem domain.

Too late for 3.1.  But I see no reason for the existing API to be
considered bad.  There is always room for improvement.  I believe you
could add support for network address ranges on top of it without too
much difficulty.

Subclass the existing classes and inherit from a mixin that keeps
track of a start and end of range and extends the 'in' operator to
check if the comparison address is >= and <= the start and end
addresses.

> To this end, now that ipaddr is moving to Python stdlib, will Google's
> contributor license agreement restriction be lifted? I would like to
> contribute, but have not been able to secure a corporate CLA from my
> employer.

You can sign a Python Software Foundation contributor agreement
instead.  http://www.python.org/psf/contrib/contrib-form/  We've been
a bit relaxed on requiring these from people at times but it is a good
thing to do for Python's sake.

No Google CLA will ever be required to make changes to anything in the
python project itself.