[issue3959] Add Google's ipaddr.py to the stdlib
David Moss added the comment: I think this might be worth a look before any hard and fast decisions are made :- http://code.google.com/p/netaddr/ -- nosy: +drkjam ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
David Moss added the comment: ipaddr appears to be on a fast track for "batteries included" status without much consultation in the wider Python community. As BDFL it's ultimately Guido's call, but it would be disappointing to see one solution being chosen wholesale without much additional discussion. There is no point in wrangling over the individual features of one library at revision x versus another at revision y. Software is a moving target. Omissions and bugs are easily dispatched. Ultimately we all want the same thing, better software that makes our lives easier. As for netaddr it is intended to cover more ground that all the other solutions out there. Here is a handy list of them :- http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule This may preclude its suitability for the standard library in any event being intended to support any and all network address types, not just IPv4 and IPv6. It is also currently, very much in beta, being about 75% feature complete with 6-9 months work of (part-time) work left on it before it can reach version 1.0 ready. A Python 3.0 version is also planned for release soon. In answer to various specific issues raised about netaddr. The need for separate IP and CIDR classes is set out in the FAQ page :- http://code.google.com/p/netaddr/wiki/NetAddrFAQ FYI, AddrRange is a (not yet abstract) base class with a start and end address covering the shared functionality of 3 subclasses (IPRange, CIDR, Wildcard) which should all interchangeable (within reason). It is also supports generic address (Addr objects) rather than just IP specific ones. Base 2 slices is not always the best way of expressing groups of network hosts, they are *one* way. With netaddr, I wanted to avoid the 'super object' syndrome that seems to dog virtuall all other existing efforts out there, and not only those in Python. In any event confusion will hopefully be dealt with as the docs improve. As for performance, netaddr's current speed for certain operations areas may be slower than other implementations but the optimisation phase of development hasn't even begun. There are loads more features to add and get working before that starts. One point I will make is on licensing. netaddr is BSD, so you can do whatever you want with it and contribute as you see fit. At the present time, contributing to ipaddr for anyone outside Google seems like the software equivalent of climbing Mount Everest! Even if I personally wanted to contribute to this particular project's efforts, having to sign the individual CLA would automatically preclude me from doing so. This is a *major* sticking point. Regardless of whatever decision is taken, netaddr will always be available as long as it has a user base, either as built in, optional extra or as a part of some wider standardisation effort. ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
David Moss added the comment: > David, in the event of netaddr's complete or partial inclusion, > are you +1 with this and the maintenance of an ip/net library > in Python? Yes, I would be very happy to help with this. > If there's going to be lots of discussion, perhaps it should be > taken to python-dev? Good idea. Peter M. and the ipaddr contributors, are you all happy to proceed in accordance with Duncan's suggestions? If so, let's kick off a thread on python-dev to get the ball rolling and see what we can come up with. ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
David Moss added the comment: For reference, here are the (cross-posted) links to the discussion on the (now failed) netaddr/ipaddr merge talks :- http://groups.google.com/group/netaddr/browse_thread/thread/f80b7c69e459 02b7 http://groups.google.com/group/ipaddr-py- dev/browse_thread/thread/2bc329151fef01eb Out of interest, here is some data from each project's download counters (taken 2nd Feb 2009) :- project: netaddr total downloads: 3298 first official release: July 7th, 2008 project: ipaddr total downloads: 998 first official release: September 24th, 2008 This only includes those accessing official releases (not direct subversion repository access). As these projects are both still less the 6 months old its probably difficult to gauge any kind of long term trend from this. However, what it does show is the high level of user interest in both projects. I have no desire to continue being a blocker on the decision to include ipaddr in the stdlib. At this point, I'm sure we are all keen to move on. As previously stated, netaddr will continue to be a viable alternative to those users that prefer its interface, documentation, additional features (layer-2 options, etc) and direction. Choice is a good thing and that choice will remain open to Python users as long as their interest persists. ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Changes by David Moss : -- nosy: -drkjam ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
