This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author exarkun
Recipients benjamin.peterson, drkjam, exarkun, giampaolo.rodola, gvanrossum, loewis, mattsmart, pmoody, shields, vstinner
Date 2009-01-01.01:36:34
SpamBayes Score 2.8254676e-11
Marked as misclassified No
Message-id <1230773796.95.0.383947217645.issue3959@psf.upfronthosting.co.za>
In-reply-to
Content
Performance shouldn't be a major concern here.  Utility is more
important and the implementation can be optimized later.

My initial impression of netaddr is pretty good.  One thing it has going
for it is documentation.  The netaddr google page gives a really great
overview of the functionality provided.  In comparison, the ipaddr-py
page is extremely sparse; the documentation in the repository is no
better (as there isn't really any).

There are a lot of minor things about ipaddr-py which are off-putting. 
It uses a naming convention that's not like any real Python software I'm
familiar with.  In particular, CamelCase method names really draw the
eye (in a bad way) and distract from the actual functionality being
provided.  I assume that if ipaddr-py is selected for inclusion, the API
will be adapted to fit PEP 8.  In comparison, netaddr appears to largely
comply with PEP 8 already.

Regarding the treatment of addresses versus address ranges, I prefer
netaddr's solution.  An address is not the same as an address range.  It
seems odd to try to represent them both with the same type as ipaddr-py
does.  This feels somewhat APLesque (where everything is a vector),
which isn't bad in itself, but generally if I want to manipulate an IP
address, I'm not thinking about it as a list of one address.  If I
wanted to do that, then I'd make a list and put the address in it.  By
comparison, the separate CIDR type in netaddr makes a lot of sense.  It
preserves a memory-efficient representation of the address range, but
does it with a different type than the fundamental address type.

This is far from a complete review of either library, obviously.  I've
done little more than glance over the documentation of each and do a
small amount of interactive playing around.  A lot more effort seems to
have gone into making netaddr accessible and appealing, and I think it
has succeeded.  Perhaps if some documentation for ipaddr-py is written
it will be easier to see where that library excels.  Of course, I assume
this is a prerequisite for inclusion in the standard library as well.
History
Date User Action Args
2009-01-01 01:36:37exarkunsetrecipients: + exarkun, gvanrossum, loewis, vstinner, giampaolo.rodola, benjamin.peterson, mattsmart, shields, pmoody, drkjam
2009-01-01 01:36:36exarkunsetmessageid: <1230773796.95.0.383947217645.issue3959@psf.upfronthosting.co.za>
2009-01-01 01:36:36exarkunlinkissue3959 messages
2009-01-01 01:36:34exarkuncreate