[issue3959] Add Google's ipaddr.py to the stdlib
Duncan McGreggor added the comment: I am a contributor to netaddr, having deprecated my own old and crufty IP address library in its favor. JP's comments on the library in this ticket are included in the set of reasons that I initially chose it to replace my own. When I first looked at the ipaddr code a month ago, the features I was delighted to see in the ipaddr project include address exclusion and address collapsing (we'd been discussing these features in netaddr since my old project had similar functionality). Perhaps the following might be a prudent course: * determine how small or big a standard library ip address module or subpackage should be; * have a mutual discussion on the netaddr and ipaddr mail lists to determine what would need to be changed in each project in order to support inclusion in the standard lib; * choose the option that requires the least code changes (simple naming convention changes should probably be given less weight than any changes to logic). As for shutting down any project that is chosen, does such an action not leave older Python versions out in the cold? Shouldn't the project remain open to support Python versions < 2.7, with a highly visible note that the code is included in 2.7/3.1+? (I am completely ignorant of related Python development policy.) -- nosy: +oubiwann ___ 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
Duncan McGreggor added the comment: >> As for shutting down any project that is chosen, does such an action not >> leave older Python versions out in the cold? Shouldn't the project >> remain open to support Python versions < 2.7, with a highly visible note >> that the code is included in 2.7/3.1+? > > Of course - hence I said "eventually". The project could continue to > maintain the external version as long as they please, provided it > doesn't diverge from the in-core version (unless it is the in-core > version itself that diverges). What I don't want to see happen is that > the community recommends at some point to ignore the outdated crappy > version in the core, and replace it with the more-powerful bug-fixed > version available separately. This has happened in the past, so I'm > extremely cautious here. Fantastic! Thanks for the clarification. 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? Guido, what is your preference regarding feature set/size for an ip/net library in Python? ___ 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
Duncan McGreggor added the comment: Well, here are my thoughts on the matter: * ipaddr is relatively small, fast, and focuses on some core functionality * netaddr is designed to be very flexible (sometimes at the cost of a little speed), leaning more towards a network calculation/address manipulation "framework" As such, and given the recent work made to ipaddr to make it stdlib-friendly, my vote would be to include ipaddr in Python while netaddr can continue growing, providing its user base with diverse functionality while hopefully taking advantage of ipaddr in the Python stdlib as much as is practical and useful. ___ 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
Duncan McGreggor added the comment: Antione, We're (netaddr) going to try to use ipaddr if possible, but there are operations which we are providing to API users that aren't directly supported by ipaddr. We haven't yet determined the level of effort involved in trying to work with ipaddr's base classes in supporting these, but it may be more effort (and code) than it's worth (the benefits of using ipaddr may be lost). In a sense, it would be a shame. But on the other hand, we have examples where 3-rd party web frameworks don't use the built-in HTTP server, and that hasn't been a problem. In many ways, netaddr is evolving into an IP manipulation framework. Those that need its features can use it; those that just need the basics will be able to get that in the stdlib. In any case, it will be in our best interest to provide some compatibility layer between the two :-) ___ 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
Duncan McGreggor added the comment: > If changes to ipaddr could make things easier for netaddr's support > of advanced features, please do propose those changes! Thanks, Guido -- we will :-) We'll be watching closely for that and participating as much as possible. ___ 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
